Skip to content

[finding] every OTHER shipped provider in rest-api-plugin.ts still absorbs the three-state ctx.getService throw — the #13904 shape, waiting one seam over #14251

Description

@os-justin

Found while implementing #13904 (PR #14250). Recorded for triage; no severity asserted and no wire consequence measurable today.

Blocked-by: #13906 (sequencing, not scope — see below).

The shape

#13904 repaired ONE of the twelve provider closures rest-api-plugin.ts hands to RestServer: objectQLProvider now absorbs only the branded "never registered" rejection (#13905's discriminator) and re-raises everything else, so the transport's wiredEngineOrLoud seam finally sees a wired-and-broken engine.

The other shipped providers — authServiceProvider, emailServiceProvider, sharingServiceProvider, reportsServiceProvider, approvalsServiceProvider, sharingRulesServiceProvider, i18nServiceProvider, analyticsServiceProvider, settingsServiceProvider, securityServiceProvider, metadataServiceProvider, and the default-project reader — all keep the superseded shape: sync ctx.getService(slot) under a catch-all returning undefined. Each therefore still collapses the same three registry facts (never registered / registered as a factory / registration failed to build) into the one value its consumer reads as "not wired".

Why this is a recorded observation and not a defect today

The collapse currently has NO observable wire consequence for these slots: their transport seams absorb anyway (computeExecCtx reaches them through seamOrUndefined, and the per-route call sites carry their own catches). Repairing the providers before those seams distinguish would be a signal-less change — the same reasoning that held #13904 behind the #13476/#13910 transport repair, recorded in its routing comment.

Why it will become the #13904 shape one seam over

#13906 (held behind #13095 at the time of this filing) pins computeExecCtx seams that these providers feed. When that family's repairs make a seam take the wiring fact from provider presence — as wiredEngineOrLoud now does for the engine — the shipped provider for that slot will absorb one layer earlier and the repair will not reach the shipped single-kernel wiring. That is precisely the defect class #13904 recorded against the engine slot, reproduced per slot.

Not folded into PR #14250, deliberately

Bounded-in-place fails on the first condition: these are different consumers with different downstream contracts (auth feeds identity resolution; settings feeds localization; email feeds a 501-style route guard), and "which conditions should re-raise" is a per-consumer judgement — the same reason #13904 was filed rather than folded into #13476. A mechanical sed of eleven catches into the engine slot's shape would assert eleven consumer contracts nobody measured.

Note for whoever takes it

The engine slot's repaired shape (async accessor + branded absorb + sync leg for KernelBase hosts) is directly copyable as a MECHANISM, but each slot owes its own consumer-side reading first: what does the seam or route do with a rejection versus an undefined, and is that seam's distinguishing repair landed yet? Doing them before their seams distinguish buys nothing observable; doing them after is one bounded edit per slot with a pin each.

Related, and distinct

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions