1.7 KiB
1.7 KiB
Table 2 — Cache Strategies and Failure Modes
Source: Session logs in HISTORY.md: 2025-12-15, 2025-12-18, 2025-12-19 Caption: Cache strategies tested for the wylab-station-14 .NET build pipeline, with their configuration, observed behavior, and disposition. Extraction type: raw_table
| Cache Strategy | Protocol | Configured On | Observed Behavior | Failure Mode | Disposition |
|---|---|---|---|---|---|
| Native Gitea act-cache-server (remote) | HTTP on port 39913 | External VPS runner (45.137.68.83) | .NET cache step: ~5 minutes (vs ~5 seconds for other steps); ETIMEDOUT connecting to 45.137.68.83:39913 from inside job containers | Full cache miss every build; job containers cannot reach port 39913 through Docker bridge | Abandoned |
| Local file cache (volume mount) | Filesystem (no HTTP) | macOS OrbStack runner | Stable cache hits; no timeout errors | No direct failure — but shared across arm64 and amd64 runners via NFS mount would cause C01 cache corruption | Adopted for single-runner use; requires architecture-tagged keys for multi-runner |
| Architecture-agnostic cache key | N/A (key design flaw) | Both runners sharing cache | arm64 cache entries with key dotnet-{hash} returned as hits for amd64 jobs (same project hash, same key) |
Silent wrong-arch artifact production: builds pass CI but produce arm64 binaries on x86-64 deployment target | Root cause of C01; fix: include runner.arch in key |
| Architecture-tagged cache key | N/A (proposed fix) | Proposed for all runners | Not yet tested as of 2025-12-19 | No known failure mode — key includes arch, making cross-arch collision impossible | Proposed as C05 fix; see H01 |