skip to content

A marker your build step honours is invisible to the deployed program — how do you pin down which survival level it has?

level: middleimportance: should knowfreq 50%

answer

  1. silence, not an exception
  2. two boundaries, two probes
  3. read the file before running anything
  4. absent in the artifact ends the search
  5. the fix lives in the declaring artifact

basics

~20 s

Probe the two boundaries. If the marker is absent from the compiled artifact's metadata, it was discarded after parsing. If it is present but a query on the loaded declaration returns nothing, it lives in the artifact yet is not queryable.

solid answer

~40 s

The symptom — honoured while building, inert in the deployed artifact — says the metadata stopped travelling somewhere between the parser and the run-time query, and there are only two boundaries it could have failed to cross. First, look at the artifact: read the compiled file's metadata for that declaration. No marker there means the level is *discarded after parsing*, and the build step saw it only because it ran inside the compilation. If the marker is in the file, run the second probe: ask the running program for the markers on the loaded declaration. Nothing returned means the level is *in the artifact, not queryable at run time*. The two probes together name the level exactly, and they also tell you the fix is in the declaring artifact rather than in your consumer.

code

pseudocode · 12 lines
pseudocode
// probe 1 - what is recorded in the deployed artifact?
inArtifact = artifactMetadata("deployed-bundle").markersOn("Account.transfer")

if not inArtifact.has("Validated"):
    level = "discarded after parsing"
else:
    // probe 2 - what does the running program see on the same declaration?
    atRunTime = load("Account").method("transfer").markers()
    if atRunTime.has("Validated"):
        level = "readable at run time"      // retention is not the fault
    else:
        level = "in the artifact, not queryable"

go deeper

for a junior

Remember that the symptom is silence, not a crash: a consumer that finds no marker simply does nothing. Learn to read the metadata recorded in a compiled artifact.

for a middle

Walk the two probes in order and say what each outcome proves. Be explicit that a missing marker in the file rules out every run-time explanation at once.

for a senior

Show that you probe the deployed artifact rather than the built one, that you rule out a consumer that never ran first, and that you know the repair belongs to the declaring artifact.

for a principal

The interesting angle is making the question answerable by anyone: if inspecting a shipped artifact's metadata is a routine command, this whole failure class stops costing redeploys.

## What the symptom already tells you "Works in the build, does nothing once deployed" is the signature failure of this axis, and it is worth being precise about why it presents as silence rather than as an error. A consumer of attached metadata is written as *act on every declaration that carries this marker*. When the metadata is not there to be found, the consumer's match set is empty, so it does no work — and doing no work is not an error condition. Nothing throws, nothing logs, and the deployment looks healthy. Before chasing retention, spend one minute ruling out the trivial alternative: that the run-time consumer never ran at all. Once you know it ran and found nothing, the question is genuinely about survival, and there are only **two boundaries** the metadata could have failed to cross. ## Two probes, in order 1. **Does it reach the artifact?** Read the compiled artifact's metadata for the declaration in question — whatever your platform offers for inspecting a compiled file without running it. If the marker is not recorded there, the level is *discarded after parsing*. Your build step saw it only because that step ran inside the compilation, while the parsed declarations were still in hand. 2. **Does the runtime expose it?** If the marker *is* in the file, load the declaration in the deployed program and ask it for its markers. If the answer is empty, the level is *stored in the artifact but not queryable at run time*. | Probe 1: in the artifact? | Probe 2: query returns it? | Level | |---|---|---| | No | — (cannot be) | Discarded after parsing | | Yes | No | In the artifact, not queryable | | Yes | Yes | Readable at run time — the level is not your problem | The third row matters as much as the other two: if both probes succeed, retention has been eliminated and the fault is somewhere else entirely — the wrong declaration, the wrong loaded copy of the type, or a consumer that never looked. ## Why you probe the artifact first The artifact probe is the cheap one and it is decisive. It requires no deployment, no running process and no reproduction of the failure, and a negative result ends the investigation immediately: metadata that is not in the file cannot be produced by any run-time mechanism. Starting from the run-time side gives you only a negative that two different levels both explain, so you would have to run the first probe anyway. A few things this sequence protects you from assuming: - **That a consumer stripped the marker.** Consumers read metadata; they do not rewrite the artifact you deployed. If the marker is missing from the file, it was never written. - **That the runtime can be persuaded.** There is no flag that reveals metadata absent from the artifact, and none that surfaces a level the runtime was never asked to keep queryable. - **That the copy you inspected is the copy you shipped.** Probe the artifact that is actually deployed, especially where a packaging step repackages or rewrites files on the way out. ## What the diagnosis licenses Once the level is named, the repair follows from it, and all of it lives in the **declaring** artifact: - Level is *discarded after parsing* and you need a run-time consumer: the marker must be re-declared at a surviving level and the code carrying it recompiled. Nothing in your consumer can substitute. - Level is *in the artifact but not queryable* and you need a run-time consumer: same conclusion, one step shorter — the declaration must be raised to the run-time-readable level and rebuilt. - Level is adequate: stop looking at metadata and go look at the consumer. Runtimes differ on the edges here in ways worth checking rather than guessing: some drop a marker from a query result when the marker's own type is not resolvable on the run-time path, some report that as an error, and some expose a marker's member values in full while others expose less than was recorded. An empty query result is therefore evidence about *this* platform's behaviour, which is why the artifact probe — which reads what was written rather than what is exposed — is the one you trust. ## The habit to build Treat "which phase does this metadata reach?" as a first-class question you can answer with a command rather than with an argument. Teams that can inspect a compiled artifact's metadata on demand resolve this class of failure in minutes; teams that cannot tend to redeploy repeatedly, change consumer configuration at random, and eventually conclude that the framework is unreliable.

  • Both probes find the marker. What have you learned?
    That retention is not the fault. The metadata is in the artifact and the runtime exposes it, so the failure is elsewhere: a consumer that never ran, a different declaration than the one you probed, or a different loaded copy of the type than the one the consumer inspected.
  • Why not just raise the level and redeploy to see if the symptom clears?
    Because it changes the declaring artifact on a guess, and if the fault was a consumer that never ran you now have a silent failure plus an unnecessary run-time contract. The artifact probe costs seconds and distinguishes the cases outright.
  • Which artifact should you inspect when the pipeline repackages the build output?
    The one actually deployed. A repackaging step reads and rewrites the file, so the metadata in the module you built is evidence about your build, not about what is running. Probe the shipped artifact, then compare with the built one if they disagree.

saying these in an interview costs you the question

  • Assumes the build step stripped the marker out of the artifact.
  • Looks for a runtime flag that exposes metadata missing from the artifact.
  • Concludes from an empty run-time query which level the marker has.
  • Expects an error rather than silence when the metadata is absent.
  • Tries to fix it entirely in the consumer, never touching the declaring artifact.