Three findings deferred from #35. They share one root: nothing in the composite action establishes which invocation is authoritative, so every publication and every reaction is decided from one run's local view.
That branch spent five review rounds adding a condition per site — an identity match, recorded ids, a status code, a head comparison — and each fix earned the next. These three want a mechanism instead.
1. Custom App identity is guessed
GET /user has no authenticated user for an installation token, and the fallback hard-codes github-actions[bot]. For any custom GitHub App the acknowledgement is created as custom-app[bot] while both settlement filters look for a different login — so 👀 is left behind permanently and 👍 never reconciles.
Most likely of the three to be hit, because it needs no concurrency at all — just a custom App token.
Fix: resolve the installation's actual bot login, or carry the identity returned when creating the reaction.
2. A stale run can withdraw the current thumb
An older findings/failed run finishing after a newer clean run reaches the deletion loop unguarded and removes a thumb that correctly describes the current head.
The code comments justify the missing guard with "the current run re-adds it on completion" — which holds only when the current run finishes last, and that is the assumption finding 3 removes.
Fix: latest-run-authoritative settlement, not another condition on the delete.
3. A clean verdict can be published for a superseded head
The clean review is posted before the head comparison in reaction settlement, so that check can neither prevent nor retract the message. The fallback issue comment is worse: it carries no commit association at all.
Not in scope of the deferral
The rest of #35 — the summary honouring report_on, the aligned footer, the finding titles, and a clean run posting an answer — is independent of all three and shipped.
Note for whoever picks this up
The reaction logic lives in bash inside action.yml, which is why five rounds of review found what no test did. Worth building the mechanism somewhere it can be exercised before adding more conditions to it.
Three findings deferred from #35. They share one root: nothing in the composite action establishes which invocation is authoritative, so every publication and every reaction is decided from one run's local view.
That branch spent five review rounds adding a condition per site — an identity match, recorded ids, a status code, a head comparison — and each fix earned the next. These three want a mechanism instead.
1. Custom App identity is guessed
GET /userhas no authenticated user for an installation token, and the fallback hard-codesgithub-actions[bot]. For any custom GitHub App the acknowledgement is created ascustom-app[bot]while both settlement filters look for a different login — so 👀 is left behind permanently and 👍 never reconciles.Most likely of the three to be hit, because it needs no concurrency at all — just a custom App token.
Fix: resolve the installation's actual bot login, or carry the identity returned when creating the reaction.
2. A stale run can withdraw the current thumb
An older findings/failed run finishing after a newer clean run reaches the deletion loop unguarded and removes a thumb that correctly describes the current head.
The code comments justify the missing guard with "the current run re-adds it on completion" — which holds only when the current run finishes last, and that is the assumption finding 3 removes.
Fix: latest-run-authoritative settlement, not another condition on the delete.
3. A clean verdict can be published for a superseded head
The clean review is posted before the head comparison in reaction settlement, so that check can neither prevent nor retract the message. The fallback issue comment is worse: it carries no commit association at all.
Not in scope of the deferral
The rest of #35 — the summary honouring
report_on, the aligned footer, the finding titles, and a clean run posting an answer — is independent of all three and shipped.Note for whoever picks this up
The reaction logic lives in bash inside
action.yml, which is why five rounds of review found what no test did. Worth building the mechanism somewhere it can be exercised before adding more conditions to it.