fix(vault)!: require RESOLVER_BASE_URL - #410
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: odal-node/dpp-engine/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (13)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe standalone vault now requires ChangesResolver URL configuration
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The standalone vault now requires RESOLVER_BASE_URL, as documented. The node and vault pass the validated value through to passport publication, and no actionable merge risk remains. 🚥 Pre-merge checks | ✅ 7✅ Passed checks (7 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
The standalone
dpp-vaultbinary signedhttps://id.odal-node.io— a host that does not resolve — into every carrier it published, whatever the environment said. #394 madeRESOLVER_BASE_URLrequired in the node and the resolver; the vault was the third reader and was missed, because its value never came from its own config at all.Where the guess lived.
PassportService::newhard-defaultedresolver_base_urlto that host, and only the node overrode it (with_resolver_base_url).dpp-vault/src/main.rsbuilds the service without the override, so every publish went through the default.The change.
PassportService::newtakes the resolver base URL as an argument. No default, andwith_resolver_base_urlis removed — no caller can build a service that signs carriers without being told where they resolve.dpp_common::config::resolver_base_url, the reader the node and the resolver use, so the three apply one rule (required, absolute http/https, no credentials/query/fragment, trailing/trimmed).a_standalone_vault_refuses_to_start_without_a_resolver_base_urlpins it. Seen failing: with a fallback restored inConfig::from_envit fails; without, it passes.https://resolver.example.com; every carrier assertion in the integration suites is host-agnostic, so none changes.dpp_common::config,.env.example,CLAUDE.md. The 0.14.0 Breaking entry gains a paragraph.Breaking only for
dpp-vaultrun as its own binary, which no image or compose file ships. The node's behaviour is unchanged — it now passes the same value through the constructor instead of the builder.Verified locally:
CARGO_BUILD_JOBS=4 just checkgreen (1343 tests, one more thanmain— the new one);cargo nextest run -p dpp-vault -p dpp-node --features integration-tests704/704.The CHANGELOG hunk sits in the Breaking entry and does not overlap #409's, so the two merge in either order.
Summary by CodeRabbit
RESOLVER_BASE_URLat startup. No default URL is provided, so configure the value explicitly. Nodes and resolvers also require this setting.RESOLVER_BASE_URLand that it has no default.