Why does a stage that reads a missing tenant id from the subscription context and scopes nothing usually pass its tests?
answer
- absence is not an error
- the default branch widens
- only the happy path is tested
- fail the subscription on missing keys
- make unscoped unrepresentable
basics
~20 sAbsence is handled as a default rather than a failure: the scoping clause is simply left out, the query succeeds, and the result is bigger rather than broken. Tests that always populate the context never execute that branch.
solid answer
~40 sReading a key nobody wrote yields an absence, not an error, so the surrounding code decides what happens — and the convenient branch is to skip the clause it cannot build. The run then succeeds and returns more rows than it should, which no assertion about a successful run will catch. Tests compound it: the pipeline is exercised with the context populated, or the query builder is called directly with a tenant in hand, so the absent branch is never reached. The reporting variant is a cross-tenant read; the audit variant writes rows with a blank owner. Hardening means treating a mandatory key's absence as a terminal failure, asserting the required keys where the subscription is opened, and running one test that subscribes with an empty context.
code
pseudocode · 5 linesfunction scopedQuery(base)
tenant = contextGet("tenant") // absence when nothing wrote the key
if tenant is absent
return base // no clause added: every tenant's rows
return base.where("tenant", tenant)go deeper
Recall that reading a missing key from a subscription context gives you an absence rather than an error, and that what your code does next decides whether anyone finds out.
Explain why the defaulting branch widens rather than narrows the result, and why a suite that always populates the context never executes that branch at all.
Show the hardening you would ship: a declared set of mandatory keys checked where the subscription is opened, absence made terminal in the stage, and one test that subscribes with an empty context.
Judge whether an unscoped query should be expressible at all — an interface whose only constructor demands the scope removes the branch instead of testing it, and that choice belongs to whoever owns the data boundary.
## The branch nobody runs A read against a subscription context returns either a value or an **absence**. The absence is data, not an error, so what happens next is entirely up to the calling stage — and the path of least resistance is to carry on without the value. In a reporting pipeline that means omitting the clause that scopes rows to a tenant. The query is still valid, the database still answers, the subscription still completes successfully, and the report contains every tenant's rows. This is the shape that makes the defect durable: - The failure **widens** the result rather than emptying it, and nothing in the pipeline treats extra rows as wrong. - No signal is produced: no failure travels down the chain, so no error handler, alert or retry sees anything. - The output is well-formed, so schema checks, row-shape assertions and serialisation all pass. - An audit variant is worse still: rows are written with a blank or default owner, and the write is the very thing you would consult later to reconstruct what happened. ## Why the test suite agrees with it | what the test does | which branch it exercises | |---|---| | subscribes with the context populated | the value-present branch only | | calls the query builder directly with a tenant argument | neither — it bypasses the context read | | runs two tenants and compares results | the value-present branch, twice | | subscribes with an empty context | the absent branch, which is the one under suspicion | Only the last row proves anything. The first three are the tests teams actually write, because the fixture that sets up a run naturally includes the identity the run is about. The absent branch exists solely to handle a situation the fixture is designed to prevent. ## The stale variant, which is worse If the identity is read from worker-bound storage rather than from the subscription, the failure mode changes character. A reused worker may still hold a previous subscription's tenant, so the clause **is** present and the query **is** scoped — to the wrong tenant. Nothing widens, nothing blanks, and the report looks entirely ordinary. Only a comparison of totals across tenants, or a customer noticing another customer's data, reveals it. This is why 'read the value from the subscription' and 'fail loudly when it is absent' are two halves of one fix rather than alternatives. ## Making absence loud 1. Declare which keys are **mandatory** for a subscription and which are genuinely optional. Most identity values are mandatory; a locale or a client hint may not be. 2. Assert the mandatory set **where the subscription is opened**, at the boundary that wrote it, so a missing key fails before any work starts and names the key. 3. In the reading stage, make absence terminal: signal a failure down the chain instead of choosing a default. A failed report is a page for the on-call engineer; a wrong report is a breach. 4. Log at the boundary, not in the stage — a log line in the stage without a failure is the same defect wearing a hat, because nobody reads a log line that accompanies a successful run. ## Designing the branch out The strongest version removes the choice rather than testing it. If the query builder cannot construct a query without a scope value — the scope is a required argument of the only constructor there is — then 'unscoped' has no representation and no branch to get wrong. The context read then happens once, at the boundary, where absence is already a terminal failure, and every stage downstream receives a value it cannot be missing. Compare the four available treatments of a missing mandatory key: | treatment | what a run does | what it costs | |---|---|---| | default to 'no restriction' | succeeds, returns everything | the defect under discussion | | default to a placeholder value | succeeds, writes wrong data | corrupts the records you audit with | | log and continue | succeeds, leaves a line nobody reads | indistinguishable from success | | fail the subscription | the run stops and names the key | one visible outage instead of a silent leak | ## What to say in the interview Name the mechanism first — a missing key is an absence, and the code chose leniency — then the reason tests miss it, then the hardening, and finish on the design point: an unscoped query that cannot be expressed cannot be shipped by accident.
- What test actually proves the hardened version?Subscribe the pipeline with an empty context and assert the run terminates with a failure naming the missing key. Keep a second test with the key populated asserting the clause is present. Only the first reaches the absent branch, and it is the one that was missing before.
- Why can this defect produce perfectly normal-looking output in production?If the identity came from a reused worker's slot rather than the subscription, the clause is present and plausible, so the report is scoped to somebody else's tenant. Nothing is blank, nothing is oversized, and the only evidence is comparing what each tenant received.
- Is logging the absence enough?No. A log line attached to a successful run competes with every other line emitted by a healthy system, and nothing routes it anywhere. If the key is mandatory, its absence has to stop the run; if stopping the run is unacceptable, the key was not actually mandatory and the leniency needs a documented owner.
saying these in an interview costs you the question
- Says a missing value would crash, so the tests would already have caught it.
- Defaults a missing tenant to 'no restriction' and calls it lenient handling.
- Tests only the populated path and treats it as covering both branches.
- Assumes an oversized result set gets noticed, since only missing rows look wrong.
- Believes logging the absence is enough without failing the subscription.