When you set one standard across many reactive services, what criteria decide whether a value may ride in the subscription context instead of an explicit stage parameter?
answer
- implicit versus explicit
- ambient and cross-cutting
- constant for the whole subscription
- small, immutable, not secret
- one boundary writes declared keys
basics
~10 sA value qualifies when it is ambient, constant for the whole subscription, small and immutable, and read by stages the value is not about. Anything a stage operates on directly stays an explicit parameter.
solid answer
~40 sThe subscription context exists for cross-cutting values that stages read without being about them — trace identity, tenant, caller identity, a deadline. Four criteria decide: the value is **ambient** (threading it through every signature would be noise), **constant** for the subscription rather than per element, **small and immutable**, and **declarable** so a missing mandatory key can be caught where the subscription is opened. Everything else stays explicit: the filter values a query is built from, per-element data, mutable accumulators, resources whose acquisition and release must be sequenced, and raw secrets that would become readable by every stage in the chain. The standard worth writing is a closed, namespaced key set, marked mandatory or optional, written at one boundary — because the cost of the mechanism is that the dependency vanishes from the signatures.
go deeper
Know that a value carried with the subscription is read by stages that never take it as an argument, which is both its point and its risk.
Explain the criteria you would apply: ambient, constant for the subscription, small and immutable, and declarable as mandatory or optional.
Argue the operational cost — contexts seeded in every test, reads that fail only at run time — and show how a mandatory-key assertion at the boundary moves that failure earlier.
Own the standard: a closed namespaced key set, one writing boundary, mandatory versus optional declared, and a rule for libraries that want a key of their own.
## What the mechanism is for A context carried with the subscription solves one problem: values that describe the unit of work must reach stages that hop between workers, including stages whose job has nothing to do with those values. An audit writer needs the tenant. A logging stage needs the trace identity. Threading both through every function signature in between turns them into noise that every intermediate stage has to accept and forward without using. That is the case the context earns. It is also a channel with no type-checked contract, and that is what a standard has to manage. ## Four criteria a value must meet - **Ambient.** It is read by stages that are not about it. A value only one stage uses is that stage's parameter. - **Constant for the subscription.** It is established before the run starts and does not change per element. The context is fixed as the subscription is established, so anything per-element belongs with the elements. - **Small and immutable.** Identifiers, not payloads. The context is copied into derived views and frequently rendered into diagnostics; a large or mutable object in there is a leak waiting to happen. - **Declarable.** You can say up front whether it is mandatory, so its absence is a failure the boundary catches rather than a default a stage invents. Trace identity, tenant, caller identity, a request deadline and a locale pass all four. That set stays small deliberately. ## What stays an explicit parameter | value | why it does not qualify | |---|---| | the filter values a query is built from | the stage is *about* them; hiding them removes them from the signature for no gain | | a per-element computation | the context is fixed for the run, so nothing written mid-run reaches another stage anyway | | a mutable accumulator | the context is immutable, and shared mutable state across stages needs an explicit sink | | a connection, a lease, an open transaction | acquisition and release must be sequenced by the code that owns them, not read ambiently | | a raw secret | every stage in the chain, including third-party operators and diagnostics, would be able to read it | The secret case deserves a sentence of its own. Carry a narrow, short-lived handle or an identity reference, and resolve the credential at the point of use, so the blast radius is one stage rather than the whole chain. ## The cost you are trading for An implicit channel buys clean signatures and pays in four places: 1. **The dependency leaves the signature.** A chain assembled without the write compiles and subscribes happily; the read returns an absence at run time, often in a service the author of the missing write does not own. 2. **Tests need seeding.** Every unit test of a reading stage now has to establish a context, and one that forgets it exercises the absent branch by accident rather than by design. 3. **Keys collide.** Ad-hoc string keys chosen by two teams composing chains from shared fragments will eventually clash or, worse, differ by a character. 4. **Refactoring is silent.** Moving a write, or splicing a fragment above rather than below a stage, changes who can read it without changing anything a reviewer would notice. ## The standard worth writing 1. A **closed key set**, defined centrally, each key namespaced and typed, each marked mandatory or optional. A team that needs a new key adds it to the set rather than inventing one locally. 2. **One writing boundary** per service — the place that opens the subscription for a unit of work. Libraries and shared fragments read; they do not write, because their position in someone else's chain decides their audience. 3. **Mandatory keys asserted at that boundary**, so a missing key fails the run immediately and names itself, instead of surfacing as a widened query three stages later. 4. **A bridging rule** for code that can only read worker-bound storage: copy in, call, clear, on the worker making the call — never leave the copy behind. ## Where the line usually gets crossed The failure is always the same: the context is a map, a map takes anything, and putting one more thing in it is cheaper today than changing five signatures. The discipline is to keep the set closed and ask the ambient test each time — does a stage that is not about this value have to read it? If no stage but the obvious one reads it, it was a parameter all along, and a reviewer should be able to say so by pointing at the key set rather than at taste.
- What breaks when a shared library stage reads a context key it never declares?A chain assembled without that write still builds and subscribes, so the failure appears at run time in somebody else's service, as an absence rather than an error. Declared keys plus a mandatory-key check at the boundary turn it into a failure at subscription time, naming the key.
- Why is a raw credential a poor fit for the subscription context?Every stage in the chain can read it, including operators from libraries and anything that renders the context into diagnostics, and the value is carried for the whole run. Carry a short-lived handle or an identity reference and resolve the credential where it is used, keeping the blast radius to one stage.
- How do you stop key collisions between teams composing chains from shared fragments?Publish a closed, namespaced key set with a typed accessor per key, and forbid ad-hoc string keys in review. The accessor makes a misspelling a build error rather than a silent absence, and the closed set forces a new key to be a deliberate, visible addition.
saying these in an interview costs you the question
- Puts anything convenient in the context because it saves changing signatures.
- Treats the context as request-scoped mutable state shared between stages.
- Believes a missing mandatory key would be caught when the chain is assembled.
- Carries large payloads or credentials because the context is 'just a map'.
- Ignores key collisions between teams composing chains from shared fragments.