Added routes_hash continuity test for the activation bridge#29191
Conversation
|
Bugbot is not enabled for this team, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdded Node imports and YAML parsing support to the route-settings activation bridge tests. Added a hash continuity suite that loads the default routes fixture and verifies legacy validation and bridge expansion produce the same fixed MD5 hash. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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 |
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx run ghost-monorepo:lint:boundaries |
✅ Succeeded | <1s | View ↗ |
nx run-many -t lint -p ghost |
✅ Succeeded | 33s | View ↗ |
nx run-many -t test:unit -p ghost |
✅ Succeeded | 29s | View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-07-10 16:55:17 UTC
bba334e to
dd23a14
Compare
3c64a76 to
f4cba0e
Compare
- getCurrentHash() is md5(JSON.stringify(...)) over the expanded settings, and
route-settings.js hardcodes the hash of the expanded default routes
('3d180d52...'). That constant is the only hash value external consumers
could compare against, so it must survive the switch from validate.js to
parser + activation bridge — this test pins both paths to it
- the existing equivalence tests use deepEqual, which is key-order-insensitive;
JSON.stringify is not, so hash continuity was untested until now
- byte-identical hashes for customized configs are not achievable: validate.js
mutates the parsed YAML in place, so its output key order (and hash) depends
on the order keys were written in the user's routes.yaml, which a normalized
domain model cannot preserve. Customized sites will get a harmless one-time
routes_hash re-sync when the read path switches — nothing reads routes_hash
except the sync comparison itself
- keeps the upcoming FileStore PR free of hash concerns: hashing stays in the
service, computed over the bridge output
f4cba0e to
b3cb7bc
Compare

ref https://linear.app/ghost/issue/HKG-1906/build-activation-bridge-in-dynamicroutingservice
Stacked on #29172.
Why
getCurrentHash()ismd5(JSON.stringify(...))over the expanded settings, androute-settings.jshardcodes the hash of the expanded default routes (3d180d52...). That constant is the only hash value external consumers could compare against, so it must survive the switch fromvalidate.jsto parser + activation bridge — this test pins both paths to it.The existing equivalence tests use
deepEqual, which is key-order-insensitive;JSON.stringifyis not, so hash continuity was untested until now.Finding worth knowing
Byte-identical hashes for customized configs are not achievable:
validate.jsmutates the parsed YAML in place, so its output key order (and hash) depends on the order keys were written in the user'sroutes.yaml, which a normalized domain model cannot preserve. Customized sites will get a harmless one-timeroutes_hashre-sync when the read path switches — nothing readsroutes_hashexcept the sync comparison itself.This also keeps the upcoming FileStore PR free of hash concerns: hashing stays in the service, computed over the bridge output.
🤖 Generated with Claude Code