Which connection's catalog the code currently running belongs to.
The problem this solves: every read of the integration catalog is keyed by INTEGRATION id, which
is shared by every connection of a connector. Threading a connection id down to each of them is
not viable — there are twenty-two call sites inside the REST connector base alone, and the
connectors that call them live in a separate repository and must keep compiling unchanged.
So the connection id travels out of band. An operation that belongs to one connection runs inside
RunInCatalogScope, and the reads underneath it resolve per-connection without being told.
This is the same mechanism the sync loop already uses for its own run context, in this very
package — IntegrationEngine imports AsyncLocalStorage for runContext and enters it around
each run and each write batch. Async context propagates across await, Promise.all and timer
callbacks, so a scope entered at the top of a run covers everything the run does.
WHAT IT DOES NOT COVER, and why that is safe: a callback scheduled OUTSIDE the scope and invoked
inside it sees no scope, and so does a task handed to a worker thread or another process. Both
fall back to the shared catalog, which is the pre-existing behaviour — over-broad, never wrong
about what exists. The failure mode of a missed scope is therefore the old behaviour, not a
corrupt one. The failure mode that WOULD be dangerous — a per-connection write landing on the
shared rows — cannot happen here, because the write path takes an explicit connection id and
never consults this scope.
Set by an owner that warms every object before reading its fields — the sync loop. Inside
such a scope a read of a cold object is a missed warm site and throws; everywhere else it
answers empty. See RunInWarmedCatalogScope.
Which connection's catalog the code currently running belongs to.
The problem this solves: every read of the integration catalog is keyed by INTEGRATION id, which is shared by every connection of a connector. Threading a connection id down to each of them is not viable — there are twenty-two call sites inside the REST connector base alone, and the connectors that call them live in a separate repository and must keep compiling unchanged.
So the connection id travels out of band. An operation that belongs to one connection runs inside
RunInCatalogScope, and the reads underneath it resolve per-connection without being told.This is the same mechanism the sync loop already uses for its own run context, in this very package —
IntegrationEngineimportsAsyncLocalStorageforrunContextand enters it around each run and each write batch. Async context propagates acrossawait,Promise.alland timer callbacks, so a scope entered at the top of a run covers everything the run does.WHAT IT DOES NOT COVER, and why that is safe: a callback scheduled OUTSIDE the scope and invoked inside it sees no scope, and so does a task handed to a worker thread or another process. Both fall back to the shared catalog, which is the pre-existing behaviour — over-broad, never wrong about what exists. The failure mode of a missed scope is therefore the old behaviour, not a corrupt one. The failure mode that WOULD be dangerous — a per-connection write landing on the shared rows — cannot happen here, because the write path takes an explicit connection id and never consults this scope.