mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 11:48:24 +00:00
Claude
cdb4f1f76e
Two small things. **The Android job's memory.** gradle.properties asks for -Xmx6g (Gradle) plus -Xmx8g and 2g metaspace (Kotlin daemon). That is roughly 16GB of ceiling on a 16GB ubuntu-latest runner, before the launcher JVM, Lint's fork and the KSP workers are counted, and no CI job overrides it. test-and-build-android is the only job that comes near that ceiling — two lint variants, two flavours of unit tests, assembleBenchmark — and it is the only job that has died: five times, each one mid-compile or mid-lint rather than at a random moment, reported as "the runner has received a shutdown signal". That is what the Linux OOM killer taking the runner agent looks like from the outside, and it is the same configuration, on the same 16GB size, that repeatedly killed the Gradle daemon in the container this branch was developed in. Capped to 4g apiece for this job only, so local builds on bigger machines keep their headroom. 4g was verified to complete lintFdroidBenchmark and both unit-test tasks; it trades some build time for a job that finishes. This corrects an earlier guess of mine, posted on the PR, that `concurrency: cancel-in-progress` was behind these. It is not: a concurrency cancel ends with conclusion `cancelled`, and these are `failure`. The cancelled runs on main are a separate and expected effect of merging quickly. **AppPreferenceStores.release.** There was no way to let go of a store, so "write the file, reopen it, check what is on disk" was impossible — which is why the migration-guard test had to be driven against the DataMigration directly rather than through a real reopen. Mirrors AccountPreferenceStores.removeAccount, including the join: cancel() only asks, and DataStore's registry entry survives until the owning job actually completes. That detail produced "there are multiple DataStores active for the same file" twice in this codebase already. Production has no reason to call it; these stores live as long as the process. Two tests now use it, and the second is the one that was missing: a migration runs when the file is first opened and does NOT run again when a later instance opens the same file — the copy-once guarantee the Cashu counter and UI settings copies both rest on, checked the way it actually happens at runtime. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AXvKXakvup4inNFfAhhr4L