osm slab hydration: never fail silently on missing config - #118
Conversation
The reason the deploy log had nothing to grep for: ensure_slab_local()
returned None via a bare `.ok()?` on AWS_S3_BUCKET_NAME and
OSM_SLAB_CACHE_DIR/RAILWAY_VOL, with zero logging on that path, and
main.rs's caller has no `else` branch on None. A deploy missing either
var produces LITERALLY NOTHING about OSM slab hydration in the boot
log — not a warning, not an error. Searching for "osm slab" was never
going to find anything on that path, which is the whole reason today's
diagnosis stalled.
Found by comparing against medcare-rs's bake_hydrate.rs / bake_s3.rs —
the same boot-time S3-hydration-onto-a-volume shape, hardened after its
own documented incident ("the silent-empty deploy earlier in this
arc"). It always logs, even in the nothing-configured case, and names
the exact variables needed:
"no source configured — ... neither S3 (AWS_ENDPOINT_URL /
AWS_S3_BUCKET_NAME / AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY)
nor GITHUB_TOKEN is set"
It also treats an EMPTY variable value the same as absent
(`.filter(|v| !v.is_empty())` in S3Config::from_env) — a Railway
variable can exist as a row with a blank value, and that must fail the
same way as not existing, not attempt a real S3 call with an empty
bucket name and fail later, differently, and less legibly.
Ported both properties into osm_slab_hydrate.rs, scoped to logging
only — the actual hydration logic (fetch, checksum-verify, cache) is
unchanged:
- env_var_nonempty(): empty treated as absent, matching bake_s3's rule.
- missing_inputs(): pure function naming every absent piece (not just
the first one hit) — testable without touching real env vars, since
ensure_slab_local() is the only caller that reads std::env::var.
- ensure_slab_local() now WARNs and names the missing variable(s)
before returning None for a missing-config reason.
Two new tests, both on the pure missing_inputs() core: names every
absent variable (not just the first — the regression this fix is for),
and stays empty (anti-vacuity) when both inputs are present.
97 passed, 0 failed (95 prior + 2 new).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe slab hydration configuration now treats missing and blank environment values as absent, reports all missing required inputs, and exits before S3 setup. Startup documentation describes the logging behavior, and regression tests cover incomplete and complete configurations. ChangesSlab hydration configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_6287bd9a-69a8-4924-b152-31c2bd1a4717) |
Diagnosing why the live
maps.oga.reddeploy 503s on/api/osm/geometry/tile/*turned up a real gap, found by comparing against MedCare-rs'sbake_hydrate.rs/bake_s3.rs— the same "boot-time S3 hydration onto a persistent volume" shape, already hardened after its own documented incident ("the silent-empty deploy earlier in this arc").The bug
Zero logging before either
?, andmain.rs's caller has noelsebranch onNone. A deploy missingAWS_S3_BUCKET_NAMEorRAILWAY_VOLproduces literally nothing about OSM slab hydration in the boot log — not a warning, not an error. This is why searching Railway's deploy logs for "osm slab" came up empty: there was structurally nothing to find on this path.The fix, ported from a working sibling
MedCare-rs's
S3Config::from_envalways logs, even in the nothing-configured case, and names the exact vars needed:It also treats an empty variable value the same as absent (
.filter(|v| !v.is_empty())) — a Railway variable can exist as a row with a blank value, and that must fail the same way as not existing, rather than attempting a real S3 call with an empty bucket name and failing later, differently, and less legibly.Ported both properties, scoped strictly to logging — the fetch/checksum/cache logic is unchanged:
env_var_nonempty()— empty treated as absent.missing_inputs()— pure function naming every absent piece, not just the first hit; testable without touching real env vars (ensure_slab_localis the only caller that readsstd::env::vardirectly).ensure_slab_local()nowtracing::warn!s and names the missing variable(s) before returningNonefor a missing-config reason.Tests
Two new, both on the pure
missing_inputs()core: names every absent variable (the actual regression this fixes — a version that only checks the first var and returns early would fail this), and stays empty (anti-vacuity) when both inputs are present.97 passed, 0 failed (95 prior from #117 + 2 new).
What this doesn't fix
This makes the failure observable, not necessarily resolved — I still don't know which of the required Railway variables is actually missing/empty on the live deploy. The next deploy's boot log will say so explicitly; from there it's a one-line env var fix on Railway's side, not a code change.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
Generated by Claude Code
Summary by CodeRabbit
Bug Fixes
Tests