fix: network bug where a message could be dropped

[titouantanguy]

Description of changes

This fixes a corner case of the network where:

• Party A calls rcv(B)
• A puts B in its completed_parties' set
• No message from B arrives during the tick_interval
• A starts the select between a sleep and rcv
• B's message finally comes through
• A consumes but discards that message, and goes back to running the loop

Effectively A drops a legitimate message from B.

Issue ticket number and link

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

Dependency Update Questionnaire (only if deps changed or added)

Answer in the Cargo.toml next to the dependency (or here if updating):

1. Ownership changes or suspicious concentration?
2. Low popularity?
3. Unusual version jump?
4. Lacking documentation?
5. Missing CI?
6. No security / disclosure policy?
7. Significant size increase?

More details and explanations for the checklist and dependency updates can be found in CONTRIBUTING.md

[github-actions]

Consolidated Tests Results 2026-06-01 - 16:48:34

Test Results

7 passed

Details

7 tests
not captured
junit-to-ctrf
build-and-test test-reporter #2485
fix: network bug where a message could be dropped #624

test-reporter: Run #2485

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
7	7	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		38.8s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		1m 56s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 8s
k8s_test_keygen_and_crs	✅		1m 51s
k8s_test_keygen_uniqueness	✅		4m 44s
k8s_test_centralized_insecure	✅		54.6s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.7s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

[Copilot]

Pull request overview

Fixes a corner case in NetworkSession::receive where, after a sender is marked as completed, a legitimate message arriving during the timeout window could be consumed but effectively discarded.

Changes:

• Adjusted the tick_interval.tick() branch in the receive loop so that if the sender is in completed_parties, an in-flight message received during the “grace period” is returned instead of being dropped.
• Renamed the post-loop packet variable (local_packet → returned_packet) to better reflect its role after the receive loop completes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jot2re]

LGTM! Although this is super subtle. Maybe it would be good to add a few more code comments?
Also as Copilot mentions, maybe adding a test validating the fix would also be good

[titouantanguy]

Will work on a test.
Note that there's already a code comment there

// The sender has said the session is complete, wait for the timeout time to ensure there is no more messages lingering

To me this implicitly say that we should consider incoming message for the next timeout time period. We just weren't doing what was written I guess ?

[github-actions]

Consolidated Tests Results 2026-06-05 - 11:29:40

Test Results

7 passed

Details

7 tests
not captured
junit-to-ctrf
build-and-test test-reporter #2601
fix: network bug where a message could be dropped #624

test-reporter: Run #2601

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
7	7	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		38.9s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		1m 52s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 5s
k8s_test_keygen_and_crs	✅		1m 51s
k8s_test_keygen_uniqueness	✅		4m 37s
k8s_test_centralized_insecure	✅		1m
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

[github-actions]

Consolidated Tests Results 2026-06-05 - 14:16:24

Test Results

7 passed

Details

7 tests
not captured
junit-to-ctrf
build-and-test test-reporter #2614
fix: network bug where a message could be dropped #624

test-reporter: Run #2614

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
7	7	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		39.0s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		1m 56s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 5s
k8s_test_keygen_and_crs	✅		1m 52s
k8s_test_keygen_uniqueness	✅		4m 38s
k8s_test_centralized_insecure	✅		1m
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

[jot2re]

Still looks good to me!
BTW I don't think I was clear previously; the comments I thought that might make sense was on the specific branches of the production code; since it is a bit tricky to follow what is returned at which depth given the nested select!'s

[titouantanguy]

Added a quite verbose comment if the code wasn't clear enough

[dvdplm]

Excellent comments both in the code and for the test. :)