skip to content

What evidence tells an automated case that a projected view is late rather than never arriving?

level: seniorimportance: nice to knowfreq 24%

answer

  1. Absence has two very different causes
  2. Elapsed time proves nothing on its own
  3. Ask where the flow's progress is visible
  4. Compare consumed position against your own write

basics

~20 s

Evidence that the flow already moved past the record: a progress position the projection has consumed to beyond that write, a terminal failure recorded against the record, or an abandoned delivery parked in a dead-letter destination. Elapsed time alone proves nothing.

solid answer

~50 s

Elapsed time is the weakest evidence available: it cannot separate a slow flow from a dropped one, and a case built on it alone reports the same red either way. Look instead for evidence that the flow has already dealt with your record. Three signals are usually there. First, the progress position the projection has consumed up to: if it is past the point where your write entered the source and the record is still absent, it was processed and discarded — a defect, not a wait. Second, a terminal outcome recorded against the record itself, such as a rejected or failed status. Third, an abandoned delivery parked in a dead-letter destination, which says the attempt was given up on rather than delayed. A case that names which of those it observed produces a diagnosis; one that merely ran out of patience produces a re-run.

code

pseudocode · 13 lines
pseudocode
if not read_path.view(orderId).exists():

    consumed = read_path.projection_progress()      # position built up to
    if consumed >= source_position_of(orderId):
        fail("processed but not projected - defect")

    if dead_letters.contains(orderId):
        fail("delivery abandoned - parked at " + dead_letters.at(orderId))

    if read_path.view_status(orderId) == "REJECTED":
        fail("terminal rejection - " + read_path.view_reason(orderId))

    fail_inconclusive("no evidence it was processed - still in flight")

go deeper

for a junior

Recall that a missing result has two very different causes: it has not arrived yet, or it never will. Know that waiting longer only ever tells you about the first one.

for a middle

Explain what a case can look at besides the clock — the position a projection has built up to, a recorded terminal status, an abandoned delivery — and why each is decisive where a deadline is not.

for a senior

Show how you turn those signals into a verdict and a message a first responder can act on, and how you handle a flow that exposes none of them without guessing which cause it was.

for a principal

Own the argument that a flow which cannot distinguish delayed from dropped is under-instrumented, and that the cost lands on every case written against it. Be ready to say what you would require before calling such a flow testable.

## Why the clock cannot answer this A case that knows only how long it has been waiting has exactly one thing to say when the projected record does not appear: *not visible yet*. That sentence is equally true of a flow running four seconds behind and of a flow that discarded the record permanently, and the difference between those two is the difference between a re-run and a defect report. Extending the deadline does not resolve the ambiguity — it moves it later and makes every run slower. The way out is to stop asking *how long has it been* and start asking *has the flow already dealt with my record*. That second question has an answer, and in most systems the answer is observable from inside the case. ## Evidence that the flow moved past your record Three signals are commonly available, in rough order of how decisive they are. 1. **The progress position the projection has built up to.** Many projections expose the point in their source they have consumed to — a position, an offset, a watermark, a last-processed timestamp. If that position is at or beyond the point at which your write entered the source, and your record is still absent from the view, then the record was seen and not projected. That is a defect, and it is now provable rather than suspected. 2. **A terminal outcome recorded for the record itself.** The record may be present in the view carrying a rejected or failed status, or present on an errors surface the projection maintains. A terminal status is a decision, and no amount of waiting reverses a decision. 3. **An abandoned delivery.** Where the flow's transport gives up after its attempts are exhausted and parks the item in a dead-letter destination, finding your record there says the delivery was abandoned rather than delayed. Nothing further arrives without intervention. Note what none of those is: a duration. Each is a fact about what the system did. ## Reading the evidence | What the case observes | What it means | What the case should do | |---|---|---| | View empty, progress position behind your write | Still in flight | Keep waiting, or report inconclusive | | View empty, progress position past your write | Processed and dropped | Fail: processed, not projected | | Record present with a terminal failed status | Rejected deliberately | Fail, quoting the recorded reason | | Record parked in the dead-letter destination | Delivery abandoned | Fail, naming the parked entry | | No progress signal of any kind exposed | Undecidable | Fail as inconclusive, and say why | The middle three rows are the point of the whole exercise: each turns a red case into a diagnosis without anyone opening a console. ## When nothing is exposed Some flows publish no position, no error surface and no parked destination a case may read. Then the honest verdict is **inconclusive**, and the case should say so in those words. It is tempting to pick a side — assert defect, or downgrade to a warning — but both are guesses, and a case that guesses gets ignored within a month. Record the missing evidence explicitly: no consumed position, no terminal status, no parked entry. That report is the useful artefact. A flow that cannot distinguish delayed from dropped is under-instrumented, and the cost of that lands on every case anyone ever writes against it. Asking the owning team to publish a progress position is a smaller request than it sounds, and it repays itself the first time a case fails. ## What the failure message should carry Evidence is only worth gathering if it survives into the message a first responder reads: - The identifier the case was looking for, and the read interface it queried. - The progress position observed, next to the position of the case's own write. - Any terminal status, and the reason recorded with it. - Whether the record was found parked, and when it was parked. - The elapsed time, last, as context rather than as the verdict. *"Order not visible after 45 seconds"* sends somebody to re-run the suite. *"Order absent from the customer list view; the projection has consumed past this record's position; no terminal status recorded; not parked"* sends them to the projection's key mapping or its filter, which is where the bug is. The second message costs a few extra reads inside the case and saves the first hour of every investigation. ## The habit Before a case fails on an absent projection, make it classify the absence. One extra branch turns *the thing did not show up* into *the thing was handled and thrown away*, and only the second is a bug report anyone can act on.

  • What should the case report when the flow exposes no progress evidence at all?
    Fail, and say the absence is undecidable rather than asserting it is a defect. The message should name what was missing — no consumed position, no terminal status, no parked entry — so the finding is an observability gap someone can close. Guessing either way trains the team to ignore the case.
  • Why is an abandoned delivery a stronger signal than a long absence?
    Abandonment is a decision the system made and recorded: the delivery was given up on after its attempts were exhausted, so nothing further arrives without intervention. A long absence is equally compatible with a backlog that is simply behind. One lets the case fail with a cause; the other only lets it fail with a duration.
  • How does this evidence change what you write in the failure message?
    It turns a duration into a diagnosis. Not visible before the deadline sends someone to re-run; processed past this record's position and still absent sends them to the projection's key mapping or its filter. Carry the observed position, any terminal status and the parked entry into the message so the first responder does not have to re-derive them.

saying these in an interview costs you the question

  • Treats every absent projection as a timing problem
  • Re-runs the case instead of classifying the absence
  • Assumes a longer deadline would have caught it
  • Ignores a terminal failure status already recorded
  • Fails with only a duration and no supporting evidence
  • Claims a defect without checking the flow's progress position