Which call sites commonly touch a deferred link after its unit of work has closed, and why do they escape review?

## The boundary is narrower than people picture it A unit of work usually spans one service call. Everything before it and everything after it runs with no loader available. The mental model that fails is thinking of the request as the boundary: in most designs the transaction closes when the service method returns, and a meaningful amount of work still happens afterwards - mapping, output, logging, dispatch. Every deferred link still unfilled at that instant is a landmine, and the mine is stepped on wherever output is produced. ## The four places it hides 1. **Output serialisation.** A mapped object is handed to the component that turns objects into a response, and that component walks whatever it finds - including links nobody intended to expose. It touches everything reachable, so the graph shape is decided by the output format, not by the use case. 2. **View or template rendering.** The same thing, one layer later: a template iterates a collection the read never fetched. Because rendering happens after the service call, the transaction is already gone. 3. **Async and background work.** An object is passed to another thread, a scheduled task or a queued job. By the time it is read, its unit of work has ended - and in the worst version the object also outlived the process boundary it was serialised across. 4. **An object kept past its request.** Stored in a cache, in a long-lived field, in a session, or returned upward and held. It works until somebody reads the one link that was never filled. ## Why each escapes review | site | what triggers the touch | why the diff looks innocent | |---|---|---| | output serialisation | reflective walk of every reachable link | there is no call site at all - a framework does the walking | | view rendering | an iteration in a template | templates are rarely reviewed as data-access code | | async work | any read in the worker | the worker looks self-contained; its input was loaded elsewhere | | cached or held object | a read minutes or hours later | the read is far away in both code and time from the load | The common factor is worth stating plainly: **a deferred read has no syntax.** A query has a call, a repository, a statement. A deferred read looks like reading a field. Reviewers can see the first and cannot see the second, so the rule *do not query in the view* is enforceable while *do not touch an unfetched link in the view* is not, unless the type system stops it. Two secondary reasons complete the picture: - **The boundary marker is on a different frame.** Whatever marks the transaction sits on the service method, so the reviewer looking at that method sees a correct, protected read - and the risky touch is not in that method. - **Tests do not reproduce the shape.** A test that wraps its assertions in an open transaction fills every link on demand and passes, so the suite is evidence of nothing here. ## The timing variant nobody plans for Three of the four sites share a second property: the gap between load and touch can be arbitrarily long. A cached object may be read an hour later; a queued job may run after a deploy; a scheduled task may pick up an object left behind by a request that has long since finished. That matters because it decouples the failure from the change that caused it. The commit that started caching a mapped object can be weeks old by the time someone adds a field whose link was never filled, and the incident then points at the innocent change. Treat *how long an object lives* as part of the review, not just *where it is read*. ## What to look for in a diff - A **mapped object type in a signature that crosses a layer** - returned from a service, accepted by a renderer, put into a queue payload, stored in a cache. - A **mapped object reaching the output boundary directly**, rather than a shape built for the response. - A collection **iterated outside the method that loaded it**, especially in output-shaping code. - Anything **stored for later** that was loaded inside a transaction. ## The structural read All four sites are the same event seen from different distances: something loaded under a transaction is read outside it. That is why the durable fix is a boundary rule - decide what leaves the transaction and in what shape - rather than a list of banned call sites. The list changes with every new output format; the rule does not.