chore(deps): affinidi-messaging-sdk 0.19.10, so a refused socket says why - #253
Merged
Conversation
… why
The transport matched the server's close frame as `Message::Close(_)` and threw
it away — `debug!("WebSocket connection closed by server")` — so every close
looked identical from here: the socket vanished and the reconnect loop went
again. Two instances of this app on one persona therefore duelled, and the user
was shown a transport error rather than "you have this open twice".
The mediator half was also lying. `WebSocketCommands::Close` carried no reason,
so all three of its senders got the same `duplicate-channel` problem report and
the same "replaced by a newer connection" close text — including a newcomer
*refused* by the duel damper, whose own connection was never displaced. That is
the inverse of what happened to it.
affinidi-tdk-rs #718 gives `Close` a reason, maps each to its own problem-report
code, and surfaces the close code and reason at WARN in the sdk.
`duplicate-channel` is preserved verbatim for the genuinely-replaced case, so
the places this repo matches on it are unaffected and no code change is needed
here — the floor and the manifest note are the change.
The eviction policy is deliberately untouched upstream: displacement is what
triggers the mediator's stored-mail redelivery, and this repo is not
representative in pulling explicitly via `message_pickup`. Raised from this side
as OpenVTC/verifiable-trust-infrastructure#1028.
Not yet observable in the e2e fixture: the mediator half is 0.18.21, and the
newest `affinidi-messaging-test-mediator` (0.2.52) still embeds 0.18.20. The
`#[ignore]`d transport e2e keeps asserting the old behaviour until a fixture
carrying 0.18.21 publishes.
fmt, clippy -D warnings, and `cargo test --workspace` pass.
Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
force-pushed
the
deps/messaging-sdk-0.19.10
branch
from
August 22, 2026 13:15
0277585 to
dd6eb20
Compare
|
🛡️ AI Agentic Security Code Review — all clear. We checked this change and found nothing to report. Keep shipping secure code! Note: for major, breaking, or feature-introducing changes, you can always request an in-depth review from the security team. |
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
2 participants
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.
Floor
affinidi-messaging-sdk0.19.9 → 0.19.10 (affinidi/affinidi-tdk-rs#718). Manifest note and lockfile only; no code changes.Why
Two instances of this app on the same persona reconnect-loop against each other and it presents as a network fault rather than as "you have this open twice". The cause is not the mediator's one-socket-per-DID rule — it is that nothing on either side ever said what happened.
WebSocketCommands::Closecarried no reason, so the handler answered all three of its senders identically — theduplicate-channelproblem report and"replaced by a newer connection". That includes a newcomer refused by the duel damper, whose own connection was never displaced: the exact inverse of true.Message::Close(_)and discarded it, loggingWebSocket connection closed by serverat debug. So even a correct reason on the wire changed nothing here.#718 gives
CloseaCloseReason, maps each to its own problem-report code and close text, and surfaces the close code and reason at WARN in the sdk.Compatibility
duplicate-channelis preserved verbatim for the genuinely-replaced case. This repo matches on it only in doc comments andopenvtc-core/tests/didcomm_transport_e2e.rs, and those are unaffected — hence a floor bump with no code change.The eviction policy is deliberately untouched upstream. Displacement is what triggers the mediator's
spawn_inbox_redelivery, and this repo is not representative in pulling stored mail explicitly viamessage_pickup— refusing outright would silently drop the stored-mail re-cover for clients that don't.Known gap
The mediator half of #718 is
affinidi-messaging-mediator0.18.21, and the newestaffinidi-messaging-test-mediator(0.2.52) still embeds 0.18.20. The#[ignore]d transport e2e therefore still exercises the old close behaviour until a fixture carrying 0.18.21 publishes; the new reasons reach a live client only against a deployed mediator ≥ 0.18.21.Verification
cargo fmt --all --check,cargo clippy --workspace --all-targets -- -D warnings, andcargo test --workspaceall pass locally.Closes the client-side half of OpenVTC/verifiable-trust-infrastructure#1028.