Run host code inside an Arc service scope - #94
Merged
Merged
Conversation
Capture scope authority at admission so host integrations can vary correlation and link cancellation without substituting a mutable principal or tenant. Share the ambient boundary with owned operations while retaining their cleanup behavior and singleton failure handling.
… class-instance principals
Structured cloning silently strips prototype-backed identity fields, leaving borrowed scopes with incomplete authority. Preserve original principals for ordinary requests while detaching and validating plain-principal snapshots. Document the creation-time factory context and borrowed-scope boundary.
Capture declared execution fields through getters while keeping the original principal for ordinary scopes. Borrow only deeply frozen plain-data principals, rejecting lossy shapes before running callbacks.
Factory contexts must not capture an invocation's correlation or linked cancellation signal, because scoped services persist across invocations. Keep per-invocation overrides only in the ambient request context and document the two lifetimes.
Construct scoped and transient services under their owning scope snapshot so invocation-only cancellation, correlation and principal copies cannot leak into cached services.
runInScope reported an unsnapshotable principal for every non-borrowable scope, including Arc-owned request scopes whose principal was never inspected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Arc for TypeScript 0.40.0 adds a supported way for host integrations to run code inside an existing Arc service scope, the first step toward constructing Chronicle reactors and reducers through Arc's dependency injection. npm publication remains disabled.
Added
ArcServer.runInScope(scope, callback, options?)runs a callback inside an existing service scope, withcurrentServices()andcurrentContext()set as they are for a request. Only the correlation ID and an extra abort signal can be supplied (RunInScopeOptions); tenant, principal, transport and severity come from the scope. Only scopes created withserver.services.createScope(context)can be borrowed; Arc's own request, query and observable-query scopes cannot. It rejects scopes from another server, singleton, closed or fabricated scopes, and scopes whose principal is not plain data. It is a trusted host API, not an authorization mechanism: commands still go through the normal pipeline.Changed
ServiceScope.identityreturns that snapshot, and the Chronicle, MongoDB and Drizzle integrations use it, so changing the original context object after a scope was created no longer changes the tenant those services use. Principals whose claims can't be cloned keep working for ordinary requests.Refs #93