Skip to content

agent-record: audit-live-rows calls every in-flight row ABANDONED on a fork PR, because CI fetches only main #726

Description

@localai-bot

What

scripts/audit-live-rows.py --check exits 1 on PR #431 with 1 abandoned ACTIVE, and passes on main with 0. The row it flags is BACKEND-TENSTORRENT-MISTRAL, whose implementation is in that very PR.

Run locally with the contributor's fork ref present, the same row reads:

| `BACKEND-TENSTORRENT-MISTRAL` | `ACTIVE` | IN-FLIGHT | unmerged commits on luzero/row/BACKEND-TENSTORRENT-MISTRAL | - |

222 live rows; 0 abandoned ACTIVE — exit 0.

Why CI disagrees

.github/workflows/ci.yml:316:

git fetch -q origin +refs/heads/main:refs/remotes/origin/main
python3 scripts/audit-live-rows.py --check

Only main is fetched. The audit distinguishes LANDED (commits naming the row on origin/main) from IN-FLIGHT (commits on a branch not yet on origin/main) from ABANDONED (neither). With no branch refs in the checkout, IN-FLIGHT is unreachable — so a row whose work is genuinely in flight is indistinguishable from one nobody is working on.

The script's own require_origin_main() docstring names exactly this hazard for a different input:

"An unfetched or missing origin/main would therefore make EVERY row look abandoned ... Absence of work and absence of information must never look the same."

The same principle applies to the branch side, and it isn't guarded there.

Consequence

Any PR that moves a row to ACTIVE before its code lands fails agent-record, deterministically. That is the normal shape of the work — the row goes ACTIVE, the implementation arrives in the same PR — so this is not an edge case. It hits external contributors hardest, since their branch lives on a fork that CI never fetches at all.

Combined with the other two ways agent-record currently fails for reasons unrelated to the change under test — the fork-ancestry abort in check-commit-trailers.py:281, and the integration step asserting all sibling checks are completed-success while they are still running — a red agent-record on a fork PR presently carries close to zero signal. That is the real cost: a gate people learn to ignore.

Possible fixes

  • Have the audit consider HEAD as a branch source. On a PR, HEAD is the merge commit and already contains the row's commits, so IN-FLIGHT becomes reachable with no extra fetch.
  • Or fetch the PR head ref in the workflow step alongside main.
  • Either way, --check should distinguish "no information about branches" from "no branch work exists", and fail closed on the former rather than reporting ABANDONED.

Found while landing #431 (#670). Not caused by that PR — reproduced by running the audit on main (clean) versus the PR branch with and without a fork ref present.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions