Repository navigation
Catalog update events can precede readable state #37422
Description
What to build
Make every public catalog update event a safe invalidation boundary: once agent.updated, command.updated, skill.updated, catalog.updated, or integration.updated is observable, the corresponding read API must already expose the rebuilt snapshot.
On V2 commit 4a7f760d25, replayable State calls domain finalize before assigning state = next. Several domain finalizers publish their public update event. A client can receive the event, immediately refetch, and receive the previous snapshot with no later invalidation.
This is observable in focused red tests for agents, commands, skill sources, and the provider/model catalog. Multi-domain config edits can mask the race because a later event triggers another refresh.
Acceptance criteria
- The first read triggered by each public update event returns the rebuilt agent, command, skill-source, integration, or catalog snapshot.
- A running TUI does not depend on an unrelated later event to observe a catalog change.
- State atomicity and async reference/catalog finalization remain intact.
- Focused event/read-order regression tests pass deterministically.
Blocked by
None - can start immediately.
Activity
kitlangton commentedon Jul 17, 2026
Draft red-test coverage is in #37427. It adds focused event/read-order assertions for agents, commands, skill sources, and the provider/model catalog; each currently observes the previous snapshot when handling its update event.
opencode-agent commentedon Jul 27, 2026
Addressed by #38983.
State.commitnow installs the rebuilt state before running domain finalizers, so public update events are read barriers: subscribers that refetch afteragent.updated,command.updated,catalog.updated,skill.updated,websearch.updated,integration.updated, or reference updates observe committed state. The PR audited every finalizer and adds a regression test that failed under the old ordering. Closing as resolved on the v2 branch.