An error report needs the revision that actually ran
During rolling deployment, attach the failing instance's revision to errors. A rollout target alone cannot identify the artifact that served a request.
By 
Paul. Architecture and infrastructure
An error report needs to identify the code running in the instance that failed. During a rolling deployment, the intended release and the executing revision can differ legitimately. Old workers may still be serving requests while new workers start. A single release label copied from the deployment controller can therefore attach the wrong source context to an otherwise accurate error report.
The 2 January 2026 Rails digest highlights Rails.app.revision for version identification. PR 56490 was opened and merged into main on 31 December 2025. These sources establish the development change and its discussion. They do not establish availability in a stable Rails version. This November 2026 analysis supplies no implementation snippet and makes no claim that the API exists in the reader's installed release.
A rollout target describes intent
Consider an illustrative release replacing revision A with revision B. While both sets of workers remain active, a request handled by A can fail after the controller has announced B as the rollout target. Labelling that failure B would direct investigation toward code that did not handle the request. The chronology explains the ambiguity without requiring a faulty deployment.
The useful label belongs to the executing instance. The deployment record still matters, because it explains which replacements were intended and when they occurred. Keeping the two identities separate allows an operator to ask whether a failure belongs to the old population, the new population or their interaction. Collapsing them removes information at precisely the time versions overlap.
A background worker needs the same care. A job enqueued before rollout may execute afterward, and a long-lived worker may retain an older application revision. Enqueue time is relevant context, but it cannot establish the code that later performed the job. This is an illustrative operating scenario, not an inspection of a private deployment or queue.
Source, artifact and process answer different questions
A source revision points toward the code used to prepare a release. An artifact identifier points toward a built package or image. An instance identifier distinguishes the process or machine involved in a particular event. Keeping those relationships available helps someone investigate a failure without pretending that any one identifier describes the whole system.
Two builds can start from the same source revision and differ in dependencies, generated files or build inputs. A source hash alone cannot prove that their bytes match. Conversely, several instances may run the same immutable artifact while differing in runtime settings or external services. Identifying the artifact is necessary for some questions and insufficient for others.
An application revision API provides a place to obtain an identifier; the meaning still depends on how that identifier was supplied or derived. It is not a reproducible-build certificate, an environment fingerprint or proof of a clean committed workspace. Those properties require their own evidence. Adding a recognizable string to an error report does not create them.
Establish the identifier before the process serves work
A proposed deployment practice is to bind release metadata to the artifact when it is prepared and make it available to the running application. This is particularly useful when the production package intentionally excludes Git metadata. An explicitly supplied build identifier can keep attribution possible without requiring a repository checkout in every worker.
The supply path needs a clear contract. If an instance reads a shared release label that is overwritten to mean the newest rollout while old workers continue running, reading that shared value later may recreate the original ambiguity. The value used for attribution should remain tied to the instance's own artifact. The exact mechanism depends on the deployment platform and the application version.
If the identifier is unavailable, a report that says so is more honest than a fabricated match to the rollout target. Preserve whatever artifact and instance information is known, then investigate the missing association. The failure to establish identity is itself an operating gap; hiding it behind a convenient default makes later evidence harder to interpret.
Use attribution to narrow investigation
For a proposed acceptance check, ask whether a report from an old instance still identifies the old artifact while its replacement serves work. Also consider a process restarted from the same artifact and a background worker that drains later. These are suggested questions for the operator's environment, not checks performed for this article.
Use the identifiers in ordinary investigation with appropriate access controls. A version value can guide source lookup and grouping, but it does not authorize access to internal logs or private repositories. Nor does a revision label explain causation: an error appearing after a release may come from changed data, configuration or another service.
Keep cache use equally deliberate. The digest mentions cache keys among possible uses, but a new revision does not automatically require invalidating every cached value. Some data is compatible across versions and some is not. Decide compatibility from the cached value's contract rather than borrowing the error-reporting identifier as a universal policy.
A platform may already solve this well
The strongest counterargument is a deployment platform that already supplies reliable per-artifact release metadata to every instance and error report. Adding another independently generated revision can create disagreement and more maintenance. Reusing the platform's trustworthy identifier can be simpler, provided its association with the executing artifact is understood.
A service with one replace-at-once process may also face less overlap than a large rolling fleet. The principle still applies, but the implementation can remain small. There is no argument here for building a new release registry when an existing identifier already answers the question. Confirm the behavior of the selected Rails version before relying on a framework convenience API.
In software maintenance, request an error record that can be traced to the instance and artifact that produced it. Retain rollout intent as separate context. That gives the next maintainer a defensible starting point while leaving build reproducibility, workspace cleanliness and environment equivalence as distinct properties to establish.