Repository navigation
feat(thumbjar): exit thumbjar prepare with its own status when Gboard's Japanese dictionary never loads - #3590
Conversation
…rd's Japanese dictionary never loads `thumbjar prepare` exited 1 for every failed step, so a caller could only tell a dictionary that never loaded on that boot from any other failure by reading the prose of its reason. That outcome comes from the boot, not the page, and a fresh emulator usually loads it. `waitForDictionary` now returns a `not-loaded` outcome of its own when no load line came by the deadline, and `dictionary.js wait` exits 3 for it. `prepare.sh` carries that status through the `prep` subshell, its deadline and its last `exit`. A capture that cannot show the load, a failed check after the load, the Japanese setup, the deadline and every other step still exit 1. The README documents both statuses. So only that wait can exit 3, `prep` now ends with an explicit success and logs the status of its last command, `adb reverse --list`, which had decided the prep's status and failed it silently. The reason the prep quotes comes only from the bytes this wait added to `ja-dictionary.log`, since a retry in the same out dir appends to it and an earlier prep may have left its last line unterminated.
…y never loads A Japanese job whose dictionary never loaded failed in prep on a reachable device, so it was red without a test result and never retried, though a fresh emulator usually loads it. `run-on-device.sh` reads `thumbjar prepare`'s exit status and, for 3 only, writes a `PREP DICTIONARY_NOT_LOADED` line to `timing.txt` beside the quoted reason. `emulator-runs.mjs retry` retries a first run with that line and a `CHECKED device` verdict once, with a `DICTIONARY_RETRY` line in the log and the job summary. A lost device stays a `DEVICE_LOST_RETRY` and an unchecked run is still not retried. The result names the dictionary as the retry's reason, and a retry whose dictionary never loaded again fails as an infrastructure failure. The job caps already cover a retry in full, so they are unchanged.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bundle Stats✅ No significant changes. All scenario measurements (37)🗺️
Significant means at least 1.0 KB and 1% gzip, or at least 5 ms and 10% import time. |
Some Japanese Android IME jobs go red before any typing: on that emulator boot Gboard never loads its Japanese dictionary, falls back to its minimal engine and cancels its dictionary pack downloads, so the prep fails after its 360-second wait. Two of the last 40 Japanese jobs failed this way. The device is reachable, so the job never retried, and its result says nothing about the editor.
thumbjar preparenow exits 3 when the dictionary never loaded and 1 for every other prep failure, so its caller can tell the two apart without reading the reason.run-on-device.shwrites aPREP DICTIONARY_NOT_LOADEDline for status 3, and the job retries once on a fresh emulator when that line comes with a reachable device, with aDICTIONARY_RETRYline in the summary. A second dictionary failure fails as infrastructure, not as a test result. Every other prep failure on a reachable device still stays red, and so does a test failure on a reachable device. The job caps already budget a full retry, so they don't change.Two things the status exposed in
prepare.share fixed in the same commit. The prep used to end with the status of its last command,adb reverse --list, which could fail the prep with no reason. The listing is diagnostic, so its status is now logged and the prep goes on. Theadb reversethat sets up the port still fails the prep. The reason the prep quotes also comes only from the bytes this wait added toja-dictionary.log, since a retry appends to the same log.Not verified on a real failing boot, since the dictionary failure can't be forced on an emulator. The unit tests use the reason a real CI boot logged.
Note
Low Risk
Changes are limited to Android CI prep, retry heuristics, and thumbjar dictionary wait exit codes—not editor runtime or production paths.
Overview
Japanese Android IME jobs could fail during device prep when Gboard never loads its Mozc dictionary on that boot, even though the emulator was fine—so CI never retried and the failure looked like a generic prep error.
thumbjar preparenow exits 3 when the dictionary wait times out (still 1 for capture faults, post-load conversion checks, and other prep failures).run-on-device.shrecordsPREP DICTIONARY_NOT_LOADEDintiming.txtfor that status, andemulator-runs.mjstreats a reachable device plus that marker like boot/adb flakes: one fresh emulator with aDICTIONARY_RETRYsummary line. A second dictionary miss on the retry is reported as infrastructure, not an editor test failure; other reachable-device prep/test failures still do not retry.The same prep work also stops
adb reverse --listfrom deciding exit status (logged only) and reads dictionary failure text only from this run’s bytes appended toja-dictionary.log, so retries do not mis-parse an earlier boot’s log.Reviewed by Cursor Bugbot for commit 8549c7d. Bugbot is set up for automated code reviews on this repo. Configure here.