Skip to content

fix(sync): publish events on injected project bus#27825

Merged
thdxr merged 2 commits into
devfrom
fix-sync-event-project-bus
May 16, 2026
Merged

fix(sync): publish events on injected project bus#27825
thdxr merged 2 commits into
devfrom
fix-sync-event-project-bus

Conversation

@thdxr
Copy link
Copy Markdown
Member

@thdxr thdxr commented May 16, 2026

Summary

  • Publish converted SyncEvent bus payloads through the injected ProjectBus service so /event subscribers see sync-backed events like message.part.updated.
  • Preserve instance/workspace context when publishing after the DB transaction.
  • Update the sync event test to subscribe through the same injected bus service.

Verification

  • bun test test/sync/index.test.ts --timeout 30000
  • bun typecheck

Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

@thdxr thdxr enabled auto-merge (squash) May 16, 2026 05:34
@thdxr thdxr merged commit 53849bd into dev May 16, 2026
10 checks passed
@thdxr thdxr deleted the fix-sync-event-project-bus branch May 16, 2026 05:56
johnnymo87 added a commit to johnnymo87/opencode that referenced this pull request May 26, 2026
…dler

The TCP listener at startListener was built via Layer.makeMemoMapUnsafe(),
creating a fresh memoMap per listener. The in-process Default webHandler
at toWebHandler used the shared @opencode-ai/core/effect/memo-map. Because
both pipelines depend on InstanceStore.Service via InstanceLayer.layer,
the distinct memoMaps caused two InstanceStore.Service instances to
materialize for the same directory, splitting Question.Service pending-
request maps and causing the Question tool to hang on submit.

Switch the listener to the shared memoMap. Both pipelines now materialize
exactly one InstanceStore.Service per directory.

Verified manually on a diagnostic build (cloudbox); pre-fix log shows
two 'creating instance' events for the same directory. After the fix,
re-deploying the post-fix build should show one 'creating instance'
event per directory.

Related: PR anomalyco#27825 (sync events on injected bus) addressed a downstream
symptom of this partition for the SessionEvent bus, but did not fix the
underlying split that affects every InstanceState-using service.

No automated regression test ships with this commit: the process-global
shared memoMap is pre-populated by app-runtime.ts at module load (via
ManagedRuntime.make(AppLayer, { memoMap })) before any test runs, which
makes counting-bootstrap tests tautological (both pre-fix and post-fix
pipelines reuse the pre-cached InstanceStore.Service). Verification is
manual via the diagnostic build's 'creating instance' log events.
johnnymo87 added a commit to johnnymo87/opencode that referenced this pull request May 28, 2026
…dler

The TCP listener at startListener was built via Layer.makeMemoMapUnsafe(),
creating a fresh memoMap per listener. The in-process Default webHandler
at toWebHandler used the shared @opencode-ai/core/effect/memo-map. Because
both pipelines depend on InstanceStore.Service via InstanceLayer.layer,
the distinct memoMaps caused two InstanceStore.Service instances to
materialize for the same directory, splitting Question.Service pending-
request maps and causing the Question tool to hang on submit.

Switch the listener to the shared memoMap. Both pipelines now materialize
exactly one InstanceStore.Service per directory.

Verified manually on a diagnostic build (cloudbox); pre-fix log shows
two 'creating instance' events for the same directory. After the fix,
re-deploying the post-fix build should show one 'creating instance'
event per directory.

Related: PR anomalyco#27825 (sync events on injected bus) addressed a downstream
symptom of this partition for the SessionEvent bus, but did not fix the
underlying split that affects every InstanceState-using service.

No automated regression test ships with this commit: the process-global
shared memoMap is pre-populated by app-runtime.ts at module load (via
ManagedRuntime.make(AppLayer, { memoMap })) before any test runs, which
makes counting-bootstrap tests tautological (both pre-fix and post-fix
pipelines reuse the pre-cached InstanceStore.Service). Verification is
manual via the diagnostic build's 'creating instance' log events.
johnnymo87 added a commit to johnnymo87/opencode that referenced this pull request May 28, 2026
…dler

The TCP listener at startListener was built via Layer.makeMemoMapUnsafe(),
creating a fresh memoMap per listener. The in-process Default webHandler
at toWebHandler used the shared @opencode-ai/core/effect/memo-map. Because
both pipelines depend on InstanceStore.Service via InstanceLayer.layer,
the distinct memoMaps caused two InstanceStore.Service instances to
materialize for the same directory, splitting Question.Service pending-
request maps and causing the Question tool to hang on submit.

Switch the listener to the shared memoMap. Both pipelines now materialize
exactly one InstanceStore.Service per directory.

Verified manually on a diagnostic build (cloudbox); pre-fix log shows
two 'creating instance' events for the same directory. After the fix,
re-deploying the post-fix build should show one 'creating instance'
event per directory.

Related: PR anomalyco#27825 (sync events on injected bus) addressed a downstream
symptom of this partition for the SessionEvent bus, but did not fix the
underlying split that affects every InstanceState-using service.

No automated regression test ships with this commit: the process-global
shared memoMap is pre-populated by app-runtime.ts at module load (via
ManagedRuntime.make(AppLayer, { memoMap })) before any test runs, which
makes counting-bootstrap tests tautological (both pre-fix and post-fix
pipelines reuse the pre-cached InstanceStore.Service). Verification is
manual via the diagnostic build's 'creating instance' log events.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant