Skip to content

Fix MeshCoreSession response and error miscorrelation#261

Closed
robekl wants to merge 8 commits into
Avi0n:devfrom
robekl:fix/meshcore-session-response-correlation
Closed

Fix MeshCoreSession response and error miscorrelation#261
robekl wants to merge 8 commits into
Avi0n:devfrom
robekl:fix/meshcore-session-response-correlation

Conversation

@robekl
Copy link
Copy Markdown
Contributor

@robekl robekl commented Mar 18, 2026

Summary

This PR fixes MeshCoreSession request/response miscorrelation by tightening how active commands accept success and error events.

The implementation is organized as a small series:

  1. Serialize generic MeshCore command responses
  2. Tighten typed MeshCore response matching
  3. Correlate routed MeshCore binary responses by node
  4. Correlate contact and private-key responses
  5. Simplify request serializer release
  6. Align MeshCoreSession docs with response matching
  7. Fail fast on binary MeshCore request errors

What changed

  • serialize generic command/ack waits so overlapping requests cannot steal each others .ok / .error events
  • stop treating unrelated .error events as belonging to the active request in generic and typed request paths
  • require exact typed-response matches where the protocol provides enough identity
  • correlate routed status/telemetry binary responses by node prefix
  • require getContact(publicKey:) to match the requested public key
  • require importPrivateKey(_) to accept only bare .ok(nil) as success
  • keep serialized binary requests fail-fast on device .error so an early rejection cannot stall the binary request serializer
  • simplify serializer cleanup with defer { release() }
  • align affected comments/docs with the current response-matching behavior

Notes on scope

A few APIs are still only serialized rather than fully correlated because the wire protocol does not expose enough identity to distinguish an unsolicited same-type event from the intended response. This PR only fixes the cases that can be made correct without inventing protocol semantics.

Binary requests intentionally remain a separate class from generic typed waits: they still fail immediately on device .error, because ignoring that event can strand the serialized binary request pipeline.

Tests

Added or updated regression coverage in MeshCoreSessionCommandCorrelationTests for:

  • concurrent generic command serialization
  • ignoring .ok responses with payloads for simple commands
  • ignoring unrelated .error during start() and getBattery()
  • ignoring wrong-node telemetry/status responses
  • ignoring wrong-index channelInfo
  • ignoring wrong-key contact
  • ignoring .ok(value:) during importPrivateKey
  • failing fast on binary request .error before messageSent
  • releasing the binary request serializer after a binary request error

Validation run on the branch:

  • cd MeshCore && swift test
  • cd MC1Services && swift test
  • xcodebuild -project MC1.xcodeproj -scheme MC1 -destination "platform=iOS Simulator,name=iPhone 16e" test

Latest binary-request follow-up additionally revalidated with:

  • cd MeshCore && swift test --filter MeshCoreSessionCommandCorrelationTests
  • cd MC1Services && swift test

Comment thread MeshCore/Sources/MeshCore/Session/RequestContext.swift Outdated
Comment thread MeshCore/Sources/MeshCore/Session/MeshCoreSession.swift Outdated
Comment thread MeshCore/Sources/MeshCore/Session/MeshCoreSession.swift
@Avi0n
Copy link
Copy Markdown
Owner

Avi0n commented Mar 21, 2026

Nice, thank you. Since this one has quite a few commits, could you squash them for me? Just to make the git history look a little cleaner.

@robekl
Copy link
Copy Markdown
Contributor Author

robekl commented Mar 23, 2026

Superseded by #264, which contains the same MeshCoreSession correlation fix as a single squashed commit plus the event-wait subscription hang fix found during validation.

@robekl robekl closed this Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants