mirror of
https://github.com/permissionlesstech/bitchat.git
synced 2026-07-25 08:05:20 +00:00
jackandClaude Fable 5
a8b741d605
The previous fix routed forceSave() through queue.async(flags: .barrier), and deinit called forceSave(). Dispatching onto the private concurrent queue from deinit is a teardown hazard: the async block resurrects self and enqueues barrier work that may not drain before process exit, so at teardown swift-testing/libdispatch waits on that outstanding work and the process never exits — the CI "Run Swift Tests (app)" job reached [144/144], then wedged for ~5 minutes and was Killed:9. This surfaced now because moving cryptographicIdentities into the persisted cache made far more test-created managers persist on deinit. Root cause confirmed locally: under LIBDISPATCH_COOPERATIVE_POOL_STRICT=1 (single-worker pool, mimicking a constrained CI runner) the old code intermittently stalled the whole suite ~15s from deinit-scheduled barrier work starving the pool; the fix is stable across 14 full coverage+parallel runs with the process exiting ~3s after the last test. Fix: - deinit no longer touches `queue`. Persistence is already durable (every mutating API persists inline within its own barrier), so deinit only does a queue-free best-effort flush if `pendingSave` is still set — a direct read of in-hand state, safe because a deallocating object has no other live references mutating `cache`. - forceSave() (lifecycle/app-termination only, never deinit) now uses a synchronous queue.sync(flags: .barrier): race-free `cache` read on the barrier context and nothing left scheduled at teardown. No re-entrant deadlock risk since it is never called from deinit. Test: test_manyManagersDeinitDoNotWedgeTeardown churns 200 managers that mutate then deinit and asserts the workload completes promptly; combined with the existing concurrent race guard (still TSan-clean) this covers the deinit path. Verified: swift test --parallel --enable-code-coverage green 14x with prompt process exit, and TSan-clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Test Harness Guide
This test suite uses an in-memory networking harness to make end-to-end and integration tests deterministic, fast, and race-free without touching production code.
In-Memory Bus
- File:
bitchatTests/Mocks/MockBLEService.swift - Registry/Adjacency: Global
registrymapspeerIDto aMockBLEServiceinstance;adjacencyrecords simulated links between peers. - Setup: Call
MockBLEService.resetTestBus()insetUp()to clear state between tests. - Topology: Use
simulateConnectedPeer(_:)andsimulateDisconnectedPeer(_:)to add/remove links.connectFullMesh()helpers in tests build larger topologies. - Handlers: Tests can observe data via
messageDeliveryHandler(decodedBitchatMessage) andpacketDeliveryHandler(rawBitchatPacket). - De‑duplication: A thread-safe
seenMessageIDsprevents duplicate deliveries during flooding/relays.
Broadcast Flooding
- Flag:
MockBLEService.autoFloodEnabled - Intent: When
true, public broadcasts propagate across the entire connected component (ignores TTL for reach) while still de‑duping to prevent loops. - Usage: Enabled in Integration tests (
setUp) to simulate large-network broadcast; disabled in E2E tests to keep routing explicit and verify TTL behavior (seePublicChatE2ETests.testZeroTTLNotRelayed).
Rehandshake Flow (Noise)
- Why: The legacy NACK recovery path was removed; recovery now relies on Noise session rehandshake after decrypt failure or desync.
- Manager:
NoiseSessionManagermanages per-peer sessions. - Pattern: On decrypt failure, proactively clear the local session and re-initiate a handshake. The peer accepts and replaces their session.
- Test:
IntegrationTests.testRehandshakeAfterDecryptionFailure- Corrupts ciphertext to induce a decrypt error.
- Calls
removeSession(for:)on the initiator’s manager beforeinitiateHandshake(with:)to avoidalreadyEstablished. - Verifies encrypt/decrypt succeeds post-rehandshake.
Tips
- Determinism: Add small async delays only where handler installation/topology changes could race the first send.
- Scoping: Keep
autoFloodEnabledtoggled only within Integration tests; always reset intearDown()to avoid cross-test contamination. - Direct vs Relay: Private messages target a specific peer when adjacent; otherwise they are surfaced to neighbors for relay and, if known, also delivered to the target.
Quick Start
- Create nodes and connect them:
let svc = MockBLEService(); svc.myPeerID = "PEER1"svc.simulateConnectedPeer("PEER2")
- Observe messages:
svc.messageDeliveryHandler = { msg in /* asserts */ }
- Enable broadcast flooding for Integration suites only:
MockBLEService.autoFloodEnabled = true