[RUM] Monaco DI "UNKNOWN service" errors survive the #1592 fix — 75% of errors on v2.159.2, now that the #1609 deploy gap is closed

[dawsontoth]

Summary

Production has finally moved off v2.156.4 — it now serves v2.159.2 (prod_fdc1142), which closes the 12-day delivery gap in #1609. That release contains the #1592 fix (commit 14865449, first tagged v2.156.5, an ancestor of the deployed commit).

The Monaco DI errors are still happening anyway:

[createInstance] um depends on UNKNOWN service actionWidgetService.
[createInstance] Fm depends on UNKNOWN service ICodeLensCache.
[createInstance] tb depends on UNKNOWN service IInlayHintsCache.
[createInstance] Lk depends on UNKNOWN service ISuggestMemories.
[createInstance] _x depends on UNKNOWN service treeViewsDndService.

So #1609's premise ("the fix never shipped") no longer explains it, and #1592's fix — removing the eager Monaco import — was not sufficient. Filing separately rather than reopening #1592, because the cause is a different one: the fix did what it claimed, and the errors survive it.

Datadog findings (last 24h, env:prod, version prod_fdc1142 only)

Events	275 unhandled source errors (55 / 55 / 53 / 52 / 52 across the five services)
Sessions	20 of 127 on this release (16%)
Handling	unhandled
Share of all errors on this release	267 of 356 (75%)

Per-session rate has not improved — it is slightly worse than when #1592 was filed (13 of 166 sessions, 7.8%, vs 20 of 127, 15.7%; different traffic mix, so treat as "unchanged at best", not a regression).

Views affected (every surface that opens an editor):

errors	view
85	/$organizationId/$clusterId/config/
60	/$organizationId/$clusterId/instance/$instanceId/databases/$databaseName/$tableName/
45	/$organizationId/$clusterId/instance/$instanceId/config/
25	/$organizationId/$clusterId/apps/
20	/$organizationId/$clusterId/logs/
20	/$organizationId/$clusterId/instance/$instanceId/logs/
20	/$organizationId/$clusterId/databases/$databaseName/$tableName/

Stacks land in toggleHighContrast-el2uNoWb.js → editor.api-OBQnf1nL.js, entered from onMouseMove → suggestHoverAnchor, i.e. hovering in the editor.

Verified against the bundle production actually serves

No RUM attribute involved — curl https://fabric.harper.fast/ and follow the chunks:

• Entry chunk assets/index-BLswmOju.js initializes RUM with version:`prod_fdc1142` .
• The eager path is genuinely fixed. editor.api-OBQnf1nL.js no longer appears as a static import of the entry — its only occurrences there are inside a dynamic-import preload manifest array. index.html's modulepreload list contains no Monaco chunk (tokenization-uOBOyHAS.js is 8.5 KB and contains none of the five service ids). [RUM] Monaco DI: 5 UNKNOWN service errors per editor load since v2.156.4 (0.56 registrations land in a lazy chunk) #1592's specific defect is gone.
• The chunk split it blamed is still there:
  • assets/editor.api-OBQnf1nL.js (2.6 MB) — contains getSingletonServiceDescriptors and the UNKNOWN service throw. Monaco core + the standalone service collection.
  • assets/toggleHighContrast-el2uNoWb.js (1.15 MB) — contains all five of actionWidgetService, ICodeLensCache, IInlayHintsCache, ISuggestMemories, treeViewsDndService. This is the monaco-editor/features/register.all chunk.
  • toggleHighContrast imports from editor.api, so ES module semantics guarantee editor.api evaluates first — before those five registerSingleton calls run. Making everything lazy doesn't change that ordering; it just moves both chunks later.

That is why removing the eager import didn't help: eagerness was never the load-bearing part. The ordering between the two chunks is.

Where to look next

src/lib/monaco/setup.ts imports monaco-editor/editor (→ editor.api) on the line above import 'monaco-editor/features/register.all', so even inside the lazy graph core evaluates before the registrations.

Two candidate root causes, in order of likelihood:

1. A duplicated registry. If rolldown emits its own copy of vs/platform/instantiation/common/extensions.js (which owns the module-level array registerSingleton pushes to) into each chunk, register.all registers into one copy while StandaloneServices reads the other, and exactly the five singletons that only register.all provides come up missing. Check with npx vite build --sourcemap and grep the sourcemap's sources for instantiation/common/extensions — more than one emitting chunk confirms it.
2. Genuine ordering. If the registry is shared, then editor.api's evaluation snapshots the descriptors, and the fix is to make the registrations evaluate before core — e.g. a single Monaco barrel module that imports features/register.all first and re-exports the API, so no consumer can reach editor.api ahead of it.

Two stale comments to clean up while in here, both now describing code that doesn't exist:

• src/lib/monaco/setup.ts's header says "it is imported at the top of main.tsx" — main.tsx doesn't reference Monaco; MonacoEditor.tsx loads it behind React.lazy.
• configMonaco.ts's doc comment presents the dynamic import() as what prevents these errors. It does prevent the eager link, but not the errors.

Impact

Cosmetic to the user in that editors still open — but 275 unhandled errors a day is 75% of this release's RUM error volume, which buries everything else, and #1592 already noted these fire per editor load. Also blocks reading #1609 as resolved: the deploy gap is closed, so anything still attributed to it needs re-checking.

Notes

No customer identifiers included; view paths are route templates with parameters unresolved.