Los ID de correlación en algunos eventos (es decir, gs.up.receive
y as.up.receive
) están duplicados.
ttn-lw-cli events subscribe --gateway-id ...
Por ejemplo:
{
"name": "gs.up.receive",
"time": "2019-05-10T08:48:36.397803Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tektelic-micro",
"eui": "647FDAFFFE0059AB"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
"raw_payload": "QKogASYAkdgBU2NToyoatD/C",
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7
}
},
"coding_rate": "4/5",
"frequency": "867900000",
"timestamp": 3375161699
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "tektelic-micro",
"eui": "647FDAFFFE0059AB"
},
"timestamp": 3375161699,
"rssi": 2,
"snr": 10,
"uplink_token": "ChwKGgoOdGVrdGVsaWMtbWljcm8SCGR/2v/+AFmrEOPCs8kM"
}
],
"received_at": "2019-05-10T08:48:36.397329Z",
"correlation_ids": [
"gs:conn:01DAGEFV4TBH5K9AVAX86NPDXM",
"gs:uplink:01DAGEW31DQZQNSCQPJ28KGFMF"
],
"gateway_channel_index": 4
},
"correlation_ids": [
"gs:conn:01DAGEFV4TBH5K9AVAX86NPDXM",
"gs:uplink:01DAGEW31DQZQNSCQPJ28KGFMF",
"gs:conn:01DAGEFV4TBH5K9AVAX86NPDXM",
"gs:uplink:01DAGEW31DQZQNSCQPJ28KGFMF"
],
"origin": "Johans-MacBook-Pro.local"
}
No hay duplicados en correlation_ids
Los ID de correlación probablemente se agreguen dos veces. Esto puede estar en el paquete de eventos donde se agregan los ID de correlación cuando están en el contexto.
sí
@htdvisser, el problema parece que los ID de correlación de la carga útil del evento se agregan a los del contexto, es decir, si tiene esto;
ctx := events.ContextWithCorrelationID(ctx, fmt.Sprintf("gs:uplink:%s", events.NewCorrelationID()))
msg.CorrelationIDs = append(msg.CorrelationIDs, events.CorrelationIDsFromContext(ctx)...)
registerReceiveUplink(ctx, conn.Gateway(), msg)
Los ID de correlación están duplicados en el evento, ya que están en ctx
y en msg
(hasta GetCorrelationIDs()
).
¿Deberíamos comprobar la unicidad aquí?
https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/events/events.go#L148
Sí, podemos mover el algoritmo de combinación en pkg/events/correlation_context.go
a su propia función ( mergeCorrelationIDs
) y usarlo en pkg/events/events.go
:
if cids := data.GetCorrelationIDs(); len(cids) > 0 {
cids = append(cids[:0:0], cids...)
sort.Strings(cids)
evt.innerEvent.CorrelationIDs = mergeCorrelationIDs(evt.innerEvent.CorrelationIDs, cids)
}
Probablemente deberíamos agregar una nota de que evt.innerEvent.CorrelationIDs
debe ordenarse (lo cual es así, porque los ID de correlación en el contexto están ordenados).
¿Cuál es el estado @ pgalic96 ?
me ocupé de cosas, hice la verificación de singularidad, algo como esto:
if data, ok := data.(interface{ GetCorrelationIDs() []string }); ok {
mapCorrelationIds := make(map[string]struct{})
for _, correlationID := range evt.innerEvent.CorrelationIDs {
mapCorrelationIds[correlationID] = struct{}{}
}
for _, correlationID := range data.GetCorrelationIDs() {
if _, ok := mapCorrelationIds[correlationID]; !ok {
evt.innerEvent.CorrelationIDs = append(evt.innerEvent.CorrelationIDs, correlationID)
}
}
}
aún no he escrito una prueba, pero sería crear un evento con TestCorrelationID
y luego proporcionar el mismo TestCorrelationID
en la carga útil, y luego verificar que la longitud de los CorrelationIDs del mensaje sea de hecho 1 y no 2.
Aparte del nombre de la variable, generalmente se ve bien, aunque evt.innerEvent.CorrelationIDs
no se deduplican de esta manera
Preferiría usar el algoritmo de combinación de @rvolosatovs (ver mi comentario). Ya dedicamos el tiempo a realizar una implementación eficiente para fusionar ID de correlación, por lo que sería una pena si fusionáramos / deduciramos con la implementación del mapa propuesta por @ pgalic96 , que es mucho menos eficiente y también devuelve ID sin clasificar.
@ pgalic96 ¿puedes dar una actualización de estado?
No he estado trabajando en eso esta semana todavía, voy a la oficina mañana después del examen. intentaremos finalizarlo mañana.
Cambiaré el código de acuerdo con la sugerencia de
Comentario más útil
Preferiría usar el algoritmo de combinación de @rvolosatovs (ver mi comentario). Ya dedicamos el tiempo a realizar una implementación eficiente para fusionar ID de correlación, por lo que sería una pena si fusionáramos / deduciramos con la implementación del mapa propuesta por @ pgalic96 , que es mucho menos eficiente y también devuelve ID sin clasificar.