Provenance: this is a carried-over observation, not a devkit-verified defect. It was one of five defect-shaped items in the 2026-08-05 Product outbound digest that rested on runs Product did not perform, and which — under product-circle#260 — were to route through devkit, get re-verified, and arrive under the investigator's name. Four of the five were verified and filed (andamio-api#735, andamio-api#741, product-circle#270, devkit#186 AC5). This one was not, and the original draft holding its repro was never posted and is not recoverable.
Filing it here so the observation is tracked rather than lost with the digest PR. It should be reproduced before anyone acts on it.
What was reported
Running register after a tx run returns HTTP 409. That is the entirety of the surviving detail — no CLI version, no command sequence, no response body, no environment.
What is not known
- Which
register subcommand and which tx run preceded it
- Whether the 409 came from the gateway or was synthesized CLI-side
- Whether the operation actually failed, or succeeded and reported a conflict
- CLI version and target environment (preprod assumed, unconfirmed)
Why it may still be real
Adjacent, previously-confirmed behavior in this area:
andamio-api#13 (closed) — course registration was non-idempotent and returned conflicts on an indexer race. A register immediately after an on-chain tx run is exactly the window that race occupied.andamio-cli#64 (closed) — typed ConflictError for 409 exists in internal/client, so a 409 has a defined CLI-side path.andamio-cli#138 (closed) — the exit-code change for conflicts shipped around the same period.
None of these confirms the report. They establish that a 409 on this path is plausible, not that it occurred.
Suggested first step
One preprod run: tx run a registration, then immediately register the same identity, and capture the full request/response pair. If it does not reproduce, close this as unreproducible — that is a legitimate outcome and cheaper than carrying it further.
Acceptance criteria
Origin: andamio-dev-kit-internal#201, closed 2026-08-17.
Provenance: this is a carried-over observation, not a devkit-verified defect. It was one of five defect-shaped items in the 2026-08-05 Product outbound digest that rested on runs Product did not perform, and which — under
product-circle#260— were to route through devkit, get re-verified, and arrive under the investigator's name. Four of the five were verified and filed (andamio-api#735,andamio-api#741,product-circle#270,devkit#186AC5). This one was not, and the original draft holding its repro was never posted and is not recoverable.Filing it here so the observation is tracked rather than lost with the digest PR. It should be reproduced before anyone acts on it.
What was reported
Running
registerafter atx runreturns HTTP 409. That is the entirety of the surviving detail — no CLI version, no command sequence, no response body, no environment.What is not known
registersubcommand and whichtx runpreceded itWhy it may still be real
Adjacent, previously-confirmed behavior in this area:
andamio-api#13(closed) — course registration was non-idempotent and returned conflicts on an indexer race. Aregisterimmediately after an on-chaintx runis exactly the window that race occupied.andamio-cli#64(closed) — typedConflictErrorfor 409 exists ininternal/client, so a 409 has a defined CLI-side path.andamio-cli#138(closed) — the exit-code change for conflicts shipped around the same period.None of these confirms the report. They establish that a 409 on this path is plausible, not that it occurred.
Suggested first step
One preprod run:
tx runa registration, then immediatelyregisterthe same identity, and capture the full request/response pair. If it does not reproduce, close this as unreproducible — that is a legitimate outcome and cheaper than carrying it further.Acceptance criteria
Origin:
andamio-dev-kit-internal#201, closed 2026-08-17.