Split out of #4432 so it is not buried when that issue closes. Unassigned — nobody is on this.
#4432's repro (v17 verification, F1) reported two distinct defects. The type-segment namespace split is fixed in #4520. This is the other one, which #4520 deliberately did not touch (Prime Directive #10 — no silent scope expansion).
Observed
Quoting the original report (step 2 aftermath):
after step 2 the overlay was listed but not dispatchable for a short window (POST answered the ADR-0110 "has no declaration" 404, then succeeded on a later call) — some cache between saveMeta and resolveRouteActionDeclaration lags the write.
So immediately after a successful PUT /api/v1/meta/action/<name>:
GET /api/v1/meta/action already lists the item, butPOST /api/v1/actions/<object>/<name> answers the ADR-0110 404 … has no declaration,- and a later identical POST succeeds.
Why it is worth its own issue
Two read surfaces disagree about the same write for a bounded but nonzero window, and the disagreement is timing-dependent, so it reads as a flake to anyone who hits it. It is also the shape a Studio "save then run" flow walks straight into.
saveMetaItem already awaits its projection before the fire-and-forget listeners (ADR-0094) and emits emitMetadataMutation synchronously; the lag is presumably downstream of that, in whatever resolveRouteActionDeclaration reads. Worth determining whether the dispatch resolver caches per-process without subscribing to the mutation event, or subscribes but is invalidated asynchronously — the fix differs.
Not reproduced here
I did not reproduce this myself; I am recording it so the observation survives #4432 closing. Original evidence: #4432, "Also observed" paragraph. Environment there: showcase under os serve --dev, admin session, main @ 1ee48bc60.
Part of the #3909 rc.1 verification (section F1) family.
Split out of #4432 so it is not buried when that issue closes. Unassigned — nobody is on this.
#4432's repro (v17 verification, F1) reported two distinct defects. The type-segment namespace split is fixed in #4520. This is the other one, which #4520 deliberately did not touch (Prime Directive #10 — no silent scope expansion).
Observed
Quoting the original report (step 2 aftermath):
So immediately after a successful
PUT /api/v1/meta/action/<name>:GET /api/v1/meta/actionalready lists the item, butPOST /api/v1/actions/<object>/<name>answers the ADR-0110404 … has no declaration,Why it is worth its own issue
Two read surfaces disagree about the same write for a bounded but nonzero window, and the disagreement is timing-dependent, so it reads as a flake to anyone who hits it. It is also the shape a Studio "save then run" flow walks straight into.
saveMetaItemalready awaits its projection before the fire-and-forget listeners (ADR-0094) and emitsemitMetadataMutationsynchronously; the lag is presumably downstream of that, in whateverresolveRouteActionDeclarationreads. Worth determining whether the dispatch resolver caches per-process without subscribing to the mutation event, or subscribes but is invalidated asynchronously — the fix differs.Not reproduced here
I did not reproduce this myself; I am recording it so the observation survives #4432 closing. Original evidence: #4432, "Also observed" paragraph. Environment there: showcase under
os serve --dev, admin session,main@1ee48bc60.Part of the #3909 rc.1 verification (section F1) family.