Repository navigation
Conversation
The checklist step told me to look for "published kind 32267". That is the release description, and it is published first and independently of the asset event, so it succeeds in exactly the runs that leave the listing broken. The line that carries the APK is 3063. Two releases have now failed with 32267 present in the log: - v2.1.2: the relay rejected the 3063 event for a missing version_code tag and the action swallowed the rejection, so the run exited 0. The listing had a release event pointing at an asset the relay did not have, leaving Install greyed out. - v2.2.0: the relay stopped responding after the screenshot uploads and the action gave up after about four seconds with "publish timed out". No 3063. Same broken listing. The re-run completed on the first attempt, so it was transient. The step now lists all four kinds in the order they appear and says plainly not to accept 32267 as proof. It also documents the re-run remedy, which is idempotent: the release description is republished and the same content-addressed assets are re-uploaded.
🤖 Automated Code Review |
Owner
Author
|
Agreed, this belongs in zapstore-publish, not here. Documenting event kinds (32267/3063/30063) and the relay's version_code requirement in this repo's checklist leaks the action's internals into the wrong repository. It will also rot the moment the action changes how it reports. Closing and replacing with a thin version that only asserts what this repo owns: that the publish step passed, that zapstore.yaml's own invariants hold, and that anything deeper is a zapstore-publish issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gap this closes
Step 7 of the release checklist says to confirm the Zapstore publish by looking for:
That is the wrong line. 32267 is the release description, published first and
independently of the asset event — so it succeeds in exactly the runs that leave the
listing broken. The event carrying the APK is 3063.
Two releases have now failed with 32267 present in the log:
version_codetag; the action awaited an array of promises rather than the promises, so the rejection surfaced as noise. Run exited 0.publish timed out. No 3063.A checklist that tells you to look for the line that is most likely to be there when
something is broken is worse than no check, because it manufactures false confidence.
What it says now
All four kinds, in the order they appear, with an explicit instruction not to accept
32267 as proof. It also documents the remedy and why it is safe: re-run the failed job
with
gh run rerun <id> --failed. The step is idempotent — it republishes the releasedescription and re-uploads the same content-addressed assets.
Documentation only.