Repository navigation
fix: a CASCADE this node answers itself is routed back to the relay - #397
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
I've scrutinized every line of your PR. Here's the report. 🧐I've aggregated the results of the automated checks for this PR below. 🏷️ Release PreviewEnsuring the release notes correctly reflect your contribution. 🖋️ Current:
✅ PR title follows conventional commit format. 🚀 Release Channel Compatibility Predicted next version:
📋 Repo HealthEnsuring the repo's joints are well-oiled (aka CI/CD). ⚙️ ✅ All required files present. Latest Version: ✅ 🔨 Build TestsMixing the ingredients and seeing if the cake rises! 🎂 ✅ All versions pass
🔒 Security (pip-audit)Shields up! Scanning for potential threats. 🛡️ ✅ No known vulnerabilities found (87 packages scanned). 🔍 LintA detailed summary of the latest automation run. 📝 ❌ ruff: issues found in 110 file(s) — see job log 📊 CoverageEnsuring every logical path is accounted for. 🛣️ ❌ 36.3% total coverage Per-file coverage (9 files)
Full report: download the ⚖️ License CheckEnsuring our CLA requirements are met. 🖋️ ✅ No license violations found. Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed. Your loyal script, at your command 🫡 |
dcec0c2 to
c00df67
Compare
A CASCADE forwarded by a relay was never answered by the upstream node. The node's own answer was routed as if it had arrived on the asking connection, and the route walk in _route_query_response skips the hop equal to that sender. For a relayed CASCADE the only authorized hop is the relay, which is that connection, so the answer was dropped with "no authorized return path". This also happened when the client supplied its own query_id. A locally produced answer arrived on no connection, so it is now routed with no sender (HIVEMIND-MSG-1 section 5.2: an answer goes to the recorded return path, never back to the peer it arrived from). Fail-before: the new asker -> R0 -> M0 test fails on dev with "the CASCADE answer never reached the asker" and passes with the fix. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
c00df67 to
1c71d9b
Compare
Governing clause, HIVEMIND-MSG-1 §5.2: "Otherwise walk
routefrom the most recent hop backwards and deliver the answer to the first return-path hop (§5.1) that names a directly connected peer other than the one the answer arrived from." and "A node delivers the answer to the return path it recorded".A CASCADE that a relay forwards to a single upstream node was never answered, even with a client-supplied
query_id. The upstream node logged "dropping CASCADE response with no authorized return path". Its own answer was passed to_route_query_responsewith the asking connection as the arrival connection. The route walk skips the hop equal to that sender, and for a relayed CASCADE that hop is the only authorized return path.A locally produced answer arrived on no connection.
handle_cascade_messagenow passesNoneas the arrival connection for it. Routing of answers that arrive from a peer or from upstream does not change. A directly connected asker is still served by the default route.The test file
tests/e2e/test_cascade_relay_answer_e2e.pyruns asker, R0 and M0 in hivescope, with only M0 answering. The first test sends a client-suppliedquery_id. It fails on dev with "the CASCADE answer never reached the asker" and passes with the change.The shipped hivemind-bus-client sends a CASCADE with no
query_id. The second test covers that shape. It depends on thequery_idfix that is already in dev. With the source change in this PR reverted, both tests fail.The suite on this branch gives 684 passed and 2 skipped.
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests