Problem
Two symptoms, one finding.
1. The cube's frozen cache-key guardian is red, and has never been green.
test-dft_stac_cube.R:62 Expected `cube_key()` to equal "638a2be11fdf".
actual: "45685ccbda33"
expected: "638a2be11fdf"
Bisected to 90f9d93 — the commit that introduced it (#38) — and every commit since. It was not green when written, at least not on this machine. It is unrelated to #51: that branch touches neither R/dft_stac_cube.R nor tests/testthat/test-dft_stac_cube.R, and stac_cube_cache_key() shares no code with stac_cache_key().
2. Nothing in CI runs the test suite. .github/workflows/ holds only pkgdown.yaml and update-citation-cff.yaml. There is no R-CMD-check.
The second is why the first survived a release cycle: every CI run is green because nothing runs the tests. v0.9.0 and v0.10.0 were both tagged over this failure — verified for v0.9.0 by checking out the tag and running the suite, not assumed.
Why it wasn't just re-frozen
Re-freezing an unexplained drift is exactly what the test's own comment forbids:
If this ever changes, existing cube caches are invalid.
The literal is a guardian of cache validity. Moving it to match observed output without knowing why it moved converts a guard into decoration — and if the drift is real, every existing cube_<key>.tif is already orphaned and nobody has been told.
So the question to settle first is which of these it is:
- The key legitimately drifted — a dependency changed what
rlang::hash() yields for one of the 18 hashed parts. sort(as.numeric(NULL)) (when months = NULL) and band_assets are the first places to look, since both are shape-sensitive. If so: re-freeze deliberately, with a NEWS line, and say that cube caches rebuild once.
- The literal was wrong when written — recorded from a different fixture state or a different machine. If so: re-freeze, and note the guard never guarded anything.
A cheap discriminator: git show 90f9d93:R/dft_stac_cube.R into a scratch file and compute the key from the fixture as it stood at that commit. If it does not produce 638a2be11fdf on any historical version either, the literal never matched.
Note the fetch-side twin (stac_cache_key) was green throughout, so rlang::hash() and sf WKB are stable on this machine for that fixture — which argues against a broad dependency drift and toward something specific to the cube's parts list.
What to do
The third item is the one that stops this recurring. Without it, the next frozen guardian can go red the day it lands and nobody will know until someone runs the suite locally.
Context
Found during #51 (PR #52). Not fixed there deliberately — out of scope, and re-freezing blind would have been worse than leaving it visible.
Problem
Two symptoms, one finding.
1. The cube's frozen cache-key guardian is red, and has never been green.
Bisected to
90f9d93— the commit that introduced it (#38) — and every commit since. It was not green when written, at least not on this machine. It is unrelated to #51: that branch touches neitherR/dft_stac_cube.Rnortests/testthat/test-dft_stac_cube.R, andstac_cube_cache_key()shares no code withstac_cache_key().2. Nothing in CI runs the test suite.
.github/workflows/holds onlypkgdown.yamlandupdate-citation-cff.yaml. There is noR-CMD-check.The second is why the first survived a release cycle: every CI run is green because nothing runs the tests.
v0.9.0andv0.10.0were both tagged over this failure — verified for v0.9.0 by checking out the tag and running the suite, not assumed.Why it wasn't just re-frozen
Re-freezing an unexplained drift is exactly what the test's own comment forbids:
The literal is a guardian of cache validity. Moving it to match observed output without knowing why it moved converts a guard into decoration — and if the drift is real, every existing
cube_<key>.tifis already orphaned and nobody has been told.So the question to settle first is which of these it is:
rlang::hash()yields for one of the 18 hashed parts.sort(as.numeric(NULL))(whenmonths = NULL) andband_assetsare the first places to look, since both are shape-sensitive. If so: re-freeze deliberately, with a NEWS line, and say that cube caches rebuild once.A cheap discriminator:
git show 90f9d93:R/dft_stac_cube.Rinto a scratch file and compute the key from the fixture as it stood at that commit. If it does not produce638a2be11fdfon any historical version either, the literal never matched.Note the fetch-side twin (
stac_cache_key) was green throughout, sorlang::hash()andsfWKB are stable on this machine for that fixture — which argues against a broad dependency drift and toward something specific to the cube's parts list.What to do
R-CMD-checkworkflow so the suite runs in CIThe third item is the one that stops this recurring. Without it, the next frozen guardian can go red the day it lands and nobody will know until someone runs the suite locally.
Context
Found during #51 (PR #52). Not fixed there deliberately — out of scope, and re-freezing blind would have been worse than leaving it visible.