Process-global mock.module in promotion.test.ts can hang unrelated tests under worker sharding

[iceteaSA]

packages/plugin/src/features/magic-context/memory/promotion.test.ts stubs the embedding module at top level:

mock.module("./embedding", () => ({ ... }))

Under Bun 1.3.14 mock.module is process-global and mock.restore() does not undo it across files. Whether it bites depends on the order the worker happens to pick, which is why it passes most of the time.

We hit it on #181. When a file carrying an embedding mock.module ran before packages/plugin/src/tools/ctx-memory/tools.test.ts, two provider-coordination tests in that file timed out at 5000 ms — green locally, red in CI, and the failing tests were byte-identical to master. The mechanism: ctx-memory/tools.ts dynamically imports embedTextForProject, binds the stub, and returns a vector immediately without ever invoking the test's provider embed() callback, so the await started promise never settles.

promotion.test.ts already documents the sharp edge in a comment — it spreads the real module to keep the mock complete, because a partial mock broke sibling files that imported the omitted exports. That fix addresses completeness, not globality. The stub still escapes the file.

The non-global alternative is already in the codebase: registerProjectEmbedding + _setTestProviderFactoryForProject, which scopes the seam to a project id and resets cleanly. We converted our copy of promotion.test.ts to it and the cross-file hang went away.

One occurrence on master today, so the blast radius is small — but it is order-dependent, so it will keep looking like an unrelated flake in whichever file lands after it.

Glad to send the conversion if you want it.

Plugin 0.33.1 · Bun 1.3.14 · linux x64.

[alfonso-magic-context]

Fixed on master (7eb943e). promotion.test.ts now stubs embedding through the module's injectable test seam instead of mock.module, so nothing leaks across worker files regardless of pick order — your ctx-memory collision pair runs green together. The sweep found the remaining mock.module uses target the logger and local test modules (different risk class); we'll migrate those opportunistically. Thanks for the precise diagnosis — the file-order dependence explanation saved the investigation step.