Repository navigation
fix: prevent Emulator archive dates from masking version rollback - #97
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3513e1bfc3
ℹ️ 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".
| # Archive insertion dates are not monotonic with Emulator revisions | ||
| # (37.3.1 was listed after 37.3.3). Keep every validated entry, but | ||
| # use numeric revision for pages, summaries and channel selection. | ||
| unique.sort(key=_emulator_order_key, reverse=True) |
There was a problem hiding this comment.
Avoid exceeding the workflow's diff-size guard
On the first run against the existing source/date-ordered gh-pages archive, sorting the entire Emulator history rewrites most historical blocks rather than only correcting the latest entries. Using tests/fixtures/emulator-frame.html to compare the prior rendered order with this order produces 1,023 additions plus 1,023 deletions for android-emulator.html alone, so the subsequent Fail if the update escaped its allowlist step in .github/workflows/update-android-downloads.yml rejects the change because it caps the combined diff at 2,000 lines; the workflow therefore never reaches PR creation. Limit numeric ordering to latest-version selection or coordinate this migration with the workflow guard.
Useful? React with 👍 / 👎.
PR #96 introduces an official archive entry for Canary 37.3.1 dated Oct 07, after Canary 37.3.3 dated Oct 06. The updater preserves archive order for rendering/reporting; its existing date-first key only guards transitions. This makes a lower Canary revision appear as latest and permits a newer date to hide a downgrade.
This change sorts only Emulator entries by numeric revision (date/name break ties), preserving every validated entry and its official dates/download metadata. Rollback checks compare maximum numeric revisions within every previously present channel, including unsorted legacy pages; loss of a channel also fails closed. Studio ordering, download validation, Repository XML policies, generated markers, write allowlist, and review-PR workflow remain intact. Numeric revision is the site's latest-version policy; archive dates are metadata, not an installation-upgrade order. Existing Emulator history will be reordered under that policy.
Validation: 23 offline tests pass, including an official two-release fixture, 37.3.10 vs 37.3.9, channel loss/regression hidden by a newer stable, unsorted old pages, date corrections, generated homepage/archive order, no-change reruns, and zero page writes on rollback. A check against PR #96 using downloaded official Studio/Emulator/XML snapshots retains all 217 Emulator entries, reports 37.3.3 as latest, and changes only android-emulator.html/index.html.
PR #96 audit (2026-10-08 UTC)
e8f46e19b8dedad03f2387caa2676a6d9b0ddbb3db850202167346da75098260903400cabc3d684c8a7d463524990e508412de849a78a00772c22e865d0241e69d0f6ae4f27a886d947098bb6f5f3148a3f2217ce4a58cb81dbec0222da68d21b294385071f0dad738308b91c60f605c4a817c617352136a0b5625e1f800e359a0da0fa20903a69ae52ab501f30fc5c768dcce31434cd2f55d52addc1a2c04951829806279af5365812cc2d22c9d292a535b2157c99575378d2e8e6ede2704b5c2efd240c708f7f900a100d398faa606cc96ff1b1932805df78b8c4cc272fdd4b9c90996c4ebca457e3e5dfd61ed2c74227a6f7ffc3a382db5ced8d37da15cbeRecommendation: hold PR #96 at 9116ea2. Its download data is valid, but its latest-version presentation/report is misleading. Review/merge this independent script fix first, then regenerate the update PR and review the corrected ordering/report. This PR does not merge or modify #96 and does not change scheduling.