Fifty-eight tickets in release 3.362 and sixteen had no Repo field

Fifty-eight tickets shipped in release 3.362, and one of our engineers couldn’t find a lot of them in the develop-to-master diff. They went looking for their commits and a chunk just weren’t there.

We pulled six of the missing ones and read them one at a time. None of them was missing work. They fell into three groups.

• A different repo. One ticket was attributed to the API repo rather than the main app repo, so it could never show up in a main-repo diff.
• Already shipped as a hotfix. Master had the commit days before release day, so develop’s diff against it was empty by definition.
• No release branch at all. A handful lived in the internal Jira-automation repo, which has no develop and no master. There was nothing for a diff tool to point at.

Three unrelated reasons, and from the ticket alone they all looked the same: “not in the diff.” One Boolean signal was standing in for three different states, and nobody could tell which one they were looking at.

The field that should have told us

Every ticket carries a Repo field, customfield_11202, and it exists to answer exactly this question. When it’s populated, one glance tells you whether a ticket belongs in a given release’s diff.

We pulled all 58 tickets in 3.362 and cross-referenced Repo against the real git history. The field was empty on 16 of them, more than a quarter of the release. Those tickets said STAGING/LIVE, the diff said nothing, and the only way to resolve the contradiction was to read commit messages by hand, repo by repo. We did that for six tickets before we saw the pattern and stopped guessing at the rest.

We backfilled all 16, matching each one against its commit history and stamping the right repo(s).

The validator we wrote first

Our first move was a stricter close-transition script. That script already gates the terminal JIRA transitions on Story Points and Sprint before it lets a POST through. We added Repo to the required-fields check for transition 101 and ran it against a batch of open tickets to see what would break.

A chunk of tickets from the internal Jira-automation repo got stuck. They don’t ship through develop/master, so “which repo did this ship in” has no answer for them, and the Repo field can’t be filled in. Forcing Repo at close time for a ticket type that structurally can’t have one made things worse. Before, we couldn’t audit those tickets later. Now we couldn’t close them at all.

We reverted the check in the same session and opened a new ticket to track a real fix.

Moving the check to the release gate

Close time is the wrong checkpoint for a question about repo topology. The fix belongs at release time. Before a version goes out, sweep every ticket on the fixVersion. Any STAGING/LIVE ticket with an empty Repo field and no clean sidecar exemption gets flagged before anyone opens the diff. That is the gap the new ticket is meant to close.

The pre-release scan already does something close to this. It reconciles the develop/master diff against the sprint and flags phantom refs and false-deploys. What it never checked was whether the Repo field existed at all. It only compared Repo against the diff once the field was populated. An empty field passed silently through a check built to catch mismatches, because an empty field has nothing to mismatch.

If your release review leans on a diff, every ticket needs to say which repo its code lives in before anyone reads that diff. Run the check at the release gate. Some tickets can’t have a repo to declare, so a close-time requirement will lock them out.

dxdev LESSON · paste into your AI coding agent
LESSON: Audit Missing Metadata At The Checkpoint Where The Question Applies, Not At The Point Of Individual Close
SOURCE: dxdev.com/blog/schema-visibility-enables-triage
WHAT HAPPENED: An engineer could not find many of the 58 tickets in the 3.362 release diff. Reading six of them showed three unrelated causes: the code lived in a different repo, it had already shipped as a hotfix, or it lived in a Jira-automation repo with no develop or master branch. The Repo field, which exists to answer exactly this, was empty on 16 tickets, so the causes could not be told apart. The author backfilled all 16 from commit history. Their first fix made Repo a required field at the close transition, but that blocked Jira-automation tickets that have no repo to declare, so it was reverted the same session. The real fix is a release-time audit that flags STAGING/LIVE tickets with an empty Repo and no sidecar exemption before anyone opens the diff. The existing pre-release scan missed this because it only checked mismatches, and an empty field is not a mismatch.
THE RULE: Enforce a metadata requirement at the checkpoint where the question it answers is actually asked, and only for the ticket types the question applies to. A validation that only compares populated values will silently pass a missing value.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does any check that compares a field against another source also fail or flag when the field is empty, rather than passing it silently?
      2. Is each required-field gate placed where the question is actually asked, and does it exempt ticket types for which the field structurally cannot apply?
      3. Can a reviewer distinguish, from the ticket alone, whether an absent diff entry means another repo, an earlier hotfix, or a repo with no release branch?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.