fix(sensing-server): wire WDP_GUARD_INTERVAL_US/WDP_TDM_* into EngineBridge (#1309)#1312
Open
erichkusuki wants to merge 1 commit into
Open
fix(sensing-server): wire WDP_GUARD_INTERVAL_US/WDP_TDM_* into EngineBridge (#1309)#1312erichkusuki wants to merge 1 commit into
erichkusuki wants to merge 1 commit into
Conversation
…Bridge EngineBridge::new built its own StreamingEngine, whose internal MultistaticFuser was hardcoded to MultistaticConfig::default() (60 ms guard) — the ruvnet#1031/ruvnet#1049 env overrides only reached the sibling multistatic_fuser field on AppState, so governed trust cycles failed against the default guard no matter what the deployment configured. - wifi-densepose-engine: add StreamingEngine::set_multistatic_config() - engine_bridge: EngineBridge::new takes Option<MultistaticConfig> - main.rs: thread the same env-derived config into both fusion paths Verified on a 2-node ESP32-S3 deployment: the failure message now reflects the configured guard, and with healthy nodes governed cycles ran 90 s with zero fusion errors. Fixes ruvnet#1309 Co-Authored-By: claude-flow <ruv@ruv.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1309
What
Threads the #1031/#1049 multistatic guard configuration (
WDP_GUARD_INTERVAL_US,WDP_SOFT_GUARD_US,WDP_TDM_SLOTS+WDP_TDM_SLOT_US) into the governed trust path:wifi-densepose-engine: newStreamingEngine::set_multistatic_config()(rebuilds the internal fuser; previously hardwired toMultistaticConfig::default()).engine_bridge.rs:EngineBridge::new()takes anOption<MultistaticConfig>and applies it to the engine (Nonekeeps today's default — all existing tests updated accordingly).main.rs: the same env-derived config already used forAppState.multistatic_fuseris now also passed toEngineBridge::new(with the samemin_nodes: 1single-node passthrough).Why
The startup log claimed the override took effect ("Multistatic fusion guard: 200000 µs hard …") while every governed cycle kept failing against the hardcoded default ("Timestamp spread … exceeds guard interval 60000 us"). With WiFi/ESP-NOW-synced ESP32 nodes drifting 10–150 ms (per the #1049 comment in
main.rs), the governed trust path could never succeed on a real multi-node deployment, regardless of configuration.Verification
Deployed on a live 2-node ESP32-S3 setup: after the patch the failure message reflects the configured guard, and with both nodes streaming (~42 pps each) governed cycles ran a 90 s observation window with zero fusion errors (
engine_error_count: 0on/api/v1/status); previously every cycle failed. The workspace builds clean viadocker/Dockerfile.rust.🤖 Generated with claude-flow