fix(test): an offline send needs no address for its counterparty - #1033
Merged
Merged
Conversation
#1030 routes an offline send by the counterparty's device id; a known BLE address is only where the transport looks first, so the send no longer refuses "no BLE address is known for the counterparty". The test pinned in #1021 still expected that refusal, and main's Rust board went red on it (a4ed751, f69f33f: dsm_sdk --lib 1042 passed, 1 failed), which also stopped the board before dsm_sdk's integration binaries. The test now pins the routing #1030 ships: with no address the contact is not refused for want of one; its send goes exactly as far as one to a contact holding an address, which on a host build is the dispatch. Verification: dsm_sdk --release send_offline_tests 1/1; every dsm_sdk integration binary the red board never reached, --no-fail-fast: 11/11 ok.
cryptskii
deleted the
fix/offline-send-test-follows-device-id-routing
branch
September 27, 2026 10:25
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.
Main is red
main's Rust board fails on a4ed751 (#1030) and on f69f33f (#1031):dsm_sdk --lib: 1042 passed, 1 failed.handlers::wallet_routes::send_offline_tests::an_offline_send_goes_where_the_sdk_has_seen_the_appliance.The failure also stopped the board before it ran
dsm_sdk's integration binaries.Why
#1030 routes an offline send by the counterparty's device id. A known BLE address is only where the transport looks first, so the send no longer refuses with "no BLE address is known for the counterparty". This test, pinned in #1021, still expected that refusal. I ran targeted suites for #1030 rather than the whole board, which is how it slipped through.
Change
The test is renamed
an_offline_send_needs_no_address_for_its_counterpartyand now pins the routing #1030 ships. A contact with no address is not refused for want of one: its send gets exactly as far as a send to a contact holding an address. On a host build, that is the dispatch.Test-only; no production code changes.
Verification
All runs
--release,--test-threads=1:dsm_sdk --lib send_offline_testsdsm_sdkintegration binary the red board never reached (--no-fail-fast)dsm_vertical_validation(run from the repo root, as the board does)