Zombie Origin Trial

An origin trial whose announced sunset never arrives: the tokens keep validating, so a site operator runs production traffic on an unsupported feature until the trial is disabled server-side without warning.

The word “zombie” is doing specific work here, not reaching for color. An origin trial is a time-boxed mechanism: a site operator registers an origin, receives a signed token, and includes it in an Origin-Trial HTTP response header to opt into a pre-Stable feature for a fixed window. The defining property is the window. When the announced end date passes and the feature is neither shipped nor removed, yet the tokens keep validating because no one disabled the trial server-side, the trial is dead by its own terms and still walking. It is past its expiry and still functioning, with no living owner driving it toward either terminal state.

Symptoms

• A feature’s tokens continue to validate weeks or months past the expiry date printed on the operator’s own registration confirmation and on chromestatus.com.
• The Origin-Trial response header is observable on production traffic for a feature whose chromestatus.com page reads “origin trial” with an expiry already in the past.
• The Chrome Origin Trials portal shows the operator’s registration as expired, while the feature still works in current Stable.
• No Intent to Ship and no Intent to Deprecate thread exists on blink-dev for the feature, despite the documented trial end having passed.
• A third-party JavaScript library bundles a token for the feature and treats it as a durable capability, with no note that the trial has ended.
• The operator’s integration has no fallback path, because the team that built it concluded from continued availability that the feature had effectively shipped.

Why It Happens

Two mechanisms separate the announced sunset from the actual one, and the gap between them is where the zombie lives.

The first is server-side enablement. An origin trial is enforced by token validation, and a token’s effect can be revoked at the trial server independently of the date encoded in the token. The Chrome team disables a stalled trial by an explicit operational step, not automatically on the expiry date. Until someone takes that step, expired-by-date tokens keep validating. The trial owner who would normally take it has frequently rotated off; disabling a trial with a live dependent population is the kind of action a successor defers, because it converts a quiet non-decision into a visible outage on real sites.

The second is the upstream governance failure. The Experiment That Became Permanent antipattern names a trial that accretes dependents and never clears either terminal state. A zombie trial is the operator-facing shadow of that same stall: where the governance entry describes a feature stuck between ship and remove inside the pipeline, this entry describes what that stall looks like to the site operator who registered a token and watched the expiry date pass with the feature still live. The project carries the stall as institutional debt; the operator carries it as an unsupported dependency they don’t know is unsupported.

What makes the trap close is a reasonable inference drawn from a misleading signal. “The token still works months after it was supposed to expire” reads, to a team shipping a product, as “the feature shipped and the expiry was a formality.” The inference is wrong. Continued validation is fully consistent with a stalled trial that no one has gotten around to disabling, and it doesn’t carry the guarantees a shipped feature carries. The operator has read availability as a contract when it is an oversight.

The Harm

The operator runs production traffic on a feature with no support and no stability guarantee, believing the opposite. The trial’s defining terms still hold even though its enforcement has lapsed: the feature may change syntax, change semantics, or disappear with no notice. The team that built on it has none of the protections a Stable feature carries (no Stable as Trust Boundary contract, no backward-compatibility commitment, no deprecation timeline) and has stopped behaving as though those protections are absent. The integration is shipping to users as production code with the guarantees of an expired experiment.

The end, when it comes, is an unmanaged migration by construction. A Deprecation Trial commits the project to a notification, a continued-use token window, and a removal date the operator can plan against. A zombie trial commits the project to none of these, because the trial was never converted to a governed sunset. The operator discovers the disablement the way every unmanaged migration is discovered: a production feature stops working, and the team learns from the incident channel that the trial they thought had shipped was an expired trial that was finally turned off.

The project carries the other side of the cost. Dead trial code remains in the browser (the trial registration, the feature gate, the implementation behind it), consuming binary size, security review, and platform-update accommodation for a feature that cleared no Intent to Ship review. Every milestone the zombie persists is a milestone of maintenance spent on code that the pipeline says should be either Stable or gone.

The compounding harm is to the trial mechanism itself. Origin Trials work only because operators trust that registration is reversible and the announced sunset is real. Each zombie teaches a different lesson. Some operators learn to treat an expired-but-working trial as a soft commitment they can keep depending on; others learn to distrust every announced expiry and to build fallbacks reflexively. Neither response is the one the trial contract assumes, and both raise the cost of running future trials.

The Way Out

For the operator, the move is to treat the registration’s expiry date as authoritative regardless of whether the token still validates. A feature whose trial has ended is unsupported the moment the date passes, even if it keeps working for months afterward; continued availability isn’t a renewal. The discipline is to monitor the trial’s chromestatus.com status and the operator’s own registration expiry, to maintain a feature-detection fallback that degrades gracefully when the feature disappears, and to refuse to promote an origin-trial feature to a load-bearing dependency without an Intent to Ship thread confirming the trial actually cleared. The Origin Trial Token Deployment pattern names the same expiry discipline from the deployment side; the antipattern is what happens when the operator deploys the token and then stops watching the date.

For the project, the remediation is to close the gap between the announced sunset and the enforced one. A trial past its expiry should transition to a named end state rather than lingering in indefinite validation: either converted to a Deprecation Trial with a committed migration window, or driven through Intent to Ship if the feature has become operationally load-bearing, or disabled server-side on the announced date with notice rather than silently months later. The forcing function is the same one the upstream governance antipattern names, an audit of active trials past their documented expiry that requires each owner to commit to ship, deprecate, or disable on a date, applied at the point of token enforcement so that “expired” and “disabled” stop drifting apart. None of these require new infrastructure; they require the trial-owner population to spend the attention the zombie consumes whether it is spent or not.

How It Plays Out

A team building an enterprise web application integrates a hardware-access feature available under an origin trial. They register the origin, deploy the token in their Origin-Trial response header, and ship. The registration confirmation names an expiry eleven months out. The date passes. The feature keeps working, because the trial was never disabled server-side after its owner moved to another team, so the team, seeing no break, concludes the feature shipped and removes the expiry reminder from their tracker. Fourteen months past the documented end, a Chrome release disables the stalled trial. The feature stops working in the field. The team’s first signal is a support escalation from a customer, and their post-incident review finds an expired token in their own deployment that had been validating for over a year.

A second team avoids the trap on an identical feature. Their integration checklist records the trial expiry as a hard date and pairs the feature with a capability-detection fallback that degrades to a documented baseline when the feature is unavailable. When the expiry passes, they check chromestatus.com, find no Intent to Ship thread, and treat the feature as unsupported despite the tokens still validating. They keep the feature behind the detection guard rather than promoting it to a hard dependency. When the trial is eventually disabled server-side, their fallback engages silently and no user-facing incident occurs.

Notes for Agent Context

When generating code that deploys an origin-trial token, an AI coding agent must treat the trial’s registered expiry date as authoritative and must not infer that a feature is shipped or supported from the token continuing to validate past that date; continued validation is consistent with a stalled trial that has not been disabled server-side and carries none of a Stable feature’s guarantees. Always pair an origin-trial feature with a capability-detection fallback (for example, a 'feature' in navigator-style guard) that degrades gracefully when the feature disappears without notice, and never promote an origin-trial feature to a hard dependency in build configuration, documentation, or release notes without an Intent to Ship thread on blink-dev confirming the trial cleared. When asked whether an origin-trial feature whose expiry has passed is safe to depend on, surface that the feature is unsupported as of the expiry date regardless of current availability, and present the unmanaged-shutdown risk rather than reading availability as a support commitment.

Related Articles

Sources

The Origin Trials framework, including token registration, the Origin-Trial response header, and trial-expiry semantics, is documented at developer.chrome.com/docs/web-platform/origin-trials, the canonical reference for how a trial is enrolled, enforced through token validation, and ended. The distinction between a token’s encoded expiry and the server-side enablement that actually gates a trial, the gap this antipattern lives in, is part of that same framework documentation. The Intent pipeline at chromium.org/blink/launching-features names ship and remove as a trial’s terminal states and doesn’t name the stranded state a zombie occupies; the absence is part of the conditions the antipattern produces. The blink-dev archive is the primary record of which trials cleared an Intent to Ship and which lapsed without one, the signal an operator needs to distinguish a shipped feature from a still-validating expired trial.

Technical Drill-Down

• Origin Trials documentation — the trial mechanism, token deployment, and the expiry semantics the antipattern abuses; explains that a trial is gated by token validation rather than by the calendar date alone.
• Chrome Origin Trials portal — the registration surface where an operator sees a registration’s expiry, the date a zombie trial outlives while its tokens keep validating.
• Chromium feature-launch documentation — the procedural states the Intent pipeline names and the terminal states a zombie trial fails to reach.
• blink-dev mailing list archive — the primary record for confirming whether a feature actually cleared Intent to Ship or lapsed; the thread an operator checks before promoting a trial feature to a dependency.
• Deprecations and Removals announcement series — the governed-sunset path; a Deprecation Trial entering this queue is the managed alternative to the unmanaged shutdown a zombie trial produces.