[devantler]

Why

A required test on the main branch failed once with no message, so nobody could tell which of its checks broke or whether it was a real regression. The likeliest cause is that it reads the list of uploaded files a few seconds too early.

What

Each check in that test now says what it expected and what it found when it fails. The list of uploaded files is read again for a short, bounded time while it is still incomplete; a missing or extra file still fails.

Fixes #904

🤖 Generated with Claude Code

[github-code-quality]

Code coverage overview

Languages: Go, C#

Go / code-coverage/test

main 89d152c	claude/ci-fix-export... b7c2099	+/-
50%	50%	0%

C# / code-coverage/dotnet

main 89d152c	claude/ci-fix-export... b7c2099	+/-
100%	100%	0%

Go / code-coverage/go

main 89d152c	claude/ci-fix-export... b7c2099	+/-
50%	50%	0%

ℹ️ Calculations represent line coverage. Results may change as calculations are updated.

---

_{Updated November 11, 2026 19:06 UTC}

[devantler]

🤖 Generated by the Agentic Engineer

@codex review

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-11T19:22:19.300755Z	b7c2099	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: b7c209933c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[devantler]

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

User trial at b7c209933c69cc33beacb2d3144bc53e56d1487e

Locally (macOS, bash 5.3): I ran bash .github/tests/test-lint-workflow-fixes.sh. Its new section drives the verify phase against a stubbed artifact listing. Before the fixture change it failed on the lagging-listing case. After the change all cases pass:

• a correct upload passes and reports artifact count=1;
• a listing that shows 0, then 0, then 1 is read three times and passes;
• a missing artifact is re-read and then fails with FAIL hosted fix exporter (ordinary): artifact count: expected 1, got 0;
• an extra artifact fails on the first read with artifact count: expected 1, got 2;
• the read-only case passes with 0 artifacts, and fails with artifact count: expected 0, got 1 when an artifact is present;
• a failed step reports step outcome: expected success, got failure, and an empty artifact name reports artifact name: expected prepare-fixes-test-name, got <empty>.

I also ran shellcheck on both changed files; it is clean.

In CI at this head: run 43072881971 passed [Test] Go Lint - Source and Credential Boundaries (which runs the test above) and all five hosted [Test] Fix Exporter scenarios: ordinary, manual, clean, read-only and export-failure. These exercise the real upload, download, listing and verify on a GitHub runner.

Repeat run: I re-ran [Test] Fix Exporter - ordinary, the scenario that failed on main. It passed again (job). GitHub only re-runs jobs from the latest attempt, so after that re-run the other four scenarios could not be re-run one by one, and a whole-run re-run (over 200 jobs) did not seem worth the runner time. They each ran once, green.

Not proven: whether the original failure was the listing lag. If it was, the re-read absorbs it. If it was something else, the next failure will now name the check that broke. "Stays green across repeated runs" rests on the two green ordinary runs here plus the runs on main after merge.

🤖 Generated with Claude Code