Repository navigation
F: stamp a publish outcome with the state version the publish last saw #114
Description
Why
From the #103 review (PR #110); low confidence. Store.recordPublish stamps the publish outcome with the task's state version as of the moment it records it. It does not use the version the publish last checked under a guard. TaskPublishing.owed() treats a settled outcome at the current version as "nothing owed".
So suppose a change by someone else lands between the publisher's last guarded write and recordPublish, and leaves the task publishable. That later state would count as settled, and no publish would be owed for it.
In today's code no such interleaving was found:
recordPublishruns right after the publisher returns, with no I/O in between.- Cancel leads to
cancelled, which is not publishable.
Needed
- Either have
PullRequestPublisher.publishreturn the state version it last saw and record that, or show that no write can land in that gap and document why.
Tests
- If a gap is found: a write in it leaves the publish owed, and the next trigger publishes.
🤖 Generated with Claude Code
Activity
mchwang commentedon Oct 4, 2026
Resolved by a fix, not just documentation. Implemented in PR #123, which is stacked on #110.
The suspected gap is real. In two places the publisher makes a GitHub call after its last Store write:
leftReady);The outcome was stamped with the version current at recording time. So a change someone else made during that call counted as seen, and a publish that change made owed could be suppressed.
The fix:
seenVersion, read where its path returns.Store.recordPublishstamps it.This issue closes when PR #123 reaches
main.F: stamp a publish outcome with the state version the publish last saw (