En una pasada de straymark followups drift --apply que extrajo follow-ups de dos AILOG distintos, dos entradas diferentes recibieron el mismo id de registro:
### FU-345 — FU-058-032 — instrumentar el arranque: emitir un log al TERMINAR cada `Subscribe`…
- **Origin**: AILOG-2026-08-06-003 §Follow-ups
- **Source-hash**: c0db6d800024
- **Status**: closed
### FU-345 — FU-058-034 — arrancar staging con esto puesto y obtener la distribución real…
- **Origin**: AILOG-2026-08-06-004 §Follow-ups
- **Source-hash**: 15f2ce95ed5b
- **Status**: open
Son entradas genuinamente distintas — distinto Origin, distinto Source-hash, distinto título — con el mismo identificador.
Por qué duele
Los comandos que resuelven por id actúan sobre la primera coincidencia. Al ejecutar:
straymark followups note FU-345 "<la medición>"
straymark followups set-status FU-345 closed
la nota aterrizó en el follow-up equivocado (el ya cerrado), y el set-status respondió OK FU-345 is already closed — nothing to change — que se lee como éxito. El follow-up que yo quería cerrar seguía abierto y sin la anotación.
El fallo es silencioso en las dos direcciones: ni el note ni el set-status avisan de que el id es ambiguo.
Contexto
Sospecho que la asignación de ids se calcula por entrada durante la extracción sin reservar el id de forma atómica entre AILOGs de la misma pasada. La descripción de followups new ya menciona el riesgo vecino:
"Assigns the id atomically and prints it, so the Charter body cites an entry that already exists instead of a reserved guess that the next drift --apply could hand to something else"
Aquí la colisión ocurre dentro de una sola invocación de drift --apply, entre dos AILOGs.
Sugerencias
- Asignar los ids de forma atómica durante la extracción, avanzando el contador por entrada creada y no por AILOG procesado.
- Detectar la ambigüedad al resolver: si un id casa con más de una entrada,
note/set-status/verify deberían fallar señalando el duplicado en vez de tomar la primera.
- Opcionalmente, que
validate marque ids duplicados en el registro — es barato y lo habría cazado antes de que yo escribiera en el sitio equivocado.
Entorno
- CLI 3.41.0
- Registro v1, ~297 entradas
- Reparado a mano renumerando la segunda entrada a un id libre;
recount confirma los contadores.
En una pasada de
straymark followups drift --applyque extrajo follow-ups de dos AILOG distintos, dos entradas diferentes recibieron el mismo id de registro:Son entradas genuinamente distintas — distinto
Origin, distintoSource-hash, distinto título — con el mismo identificador.Por qué duele
Los comandos que resuelven por id actúan sobre la primera coincidencia. Al ejecutar:
la nota aterrizó en el follow-up equivocado (el ya cerrado), y el
set-statusrespondióOK FU-345 is already closed — nothing to change— que se lee como éxito. El follow-up que yo quería cerrar seguía abierto y sin la anotación.El fallo es silencioso en las dos direcciones: ni el
noteni elset-statusavisan de que el id es ambiguo.Contexto
Sospecho que la asignación de ids se calcula por entrada durante la extracción sin reservar el id de forma atómica entre AILOGs de la misma pasada. La descripción de
followups newya menciona el riesgo vecino:Aquí la colisión ocurre dentro de una sola invocación de
drift --apply, entre dos AILOGs.Sugerencias
note/set-status/verifydeberían fallar señalando el duplicado en vez de tomar la primera.validatemarque ids duplicados en el registro — es barato y lo habría cazado antes de que yo escribiera en el sitio equivocado.Entorno
recountconfirma los contadores.