From 6cdc577f9147387461190974104480d08a667cd7 Mon Sep 17 00:00:00 2001 From: Ross Golder Date: Tue, 6 Oct 2026 13:17:02 +0700 Subject: [PATCH] Require the 3063 asset event as proof of a Zapstore publish 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. --- AGENTS.md | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 95eb7b7..9cfc684 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -285,16 +285,37 @@ deliberately excluded and will publish nothing. `release.yml` sets `skip-if-unconfigured: 'true'`, so **a green run does not prove the Zapstore publish happened** — a missing or invalid `ZAPSTORE_SIGN_WITH` exits -success having published nothing. Look for these lines in the `Publish to Zapstore` -step: +success having published nothing. + +Four kinds are published, and **the one that carries the APK is `3063`**. Check for +all of them, in this order: ``` APK resolved from ... sms2webhook-vX.Y.Z-release-signed.apk org.golder.sms2webhook X.Y.Z (code N), certificate ... via v2 uploaded sms2webhook/src/main/ic_launcher-playstore.png (...) -published kind 32267 ... +published kind 32267 ... release description +published kind 3063 ... asset event - THE APK +published kind 30063 ... metadata ``` +**Do not accept `32267` as proof of a publish.** It 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. Two releases have now failed this way 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: **Install greyed out**. +- v2.2.0 — the relay stopped responding partway through; the action gave up after + about four seconds and logged `publish timed out`. No 3063, so the listing was in the + same state again. + +If the step fails, or if `published kind 3063` is absent from a green run, **re-run the +failed job** (`gh run rerun --failed`) before cutting anything else. The v2.2.0 +failure was transient and completed on the first re-run. The step is idempotent: it +republishes the release description and re-uploads the same content-addressed assets. + The `uploaded ic_launcher-playstore.png` line is how you confirm the listing icon actually reached the CDN. Without an `icon:` field in `zapstore.yaml` the kind 32267 event carries no icon tag and the store shows a placeholder letter instead, which