mirror of
https://github.com/logos-messaging/logos-messaging-nim.git
synced 2026-08-27 08:21:09 +00:00
* test(e2e): drive the isolated channel peer from the test process The channel peer could only fire one message at start-up and then idle, which is all the two delivery tests we have need. The tests still living in the interop repo need more: a peer that reports its multiaddr so the node under test can dial it, sends further messages on demand, cycles the channel under the same id, and reports what it received itself. Add a command queue and an event queue to the worker so the parent can drive it after start-up, make the initial payload optional (a peer that only receives), and skip the connection wait when the peer has no staticnodes to dial. * test(e2e): give every channel test a per-run channel id SDS persists its state per channelId and restores it on create, so the fixed ids these tests used carried one run's causal history into the next and made repeated local runs diverge from a clean CI run. Call unique_channel_id(), which has been sitting unused in wrapper_helpers since the delivery tests landed, and rename the constants it now seeds from *_ID to *_PREFIX so the name says what the value is. * test(e2e): port the remaining channel delivery scenarios Six channel tests were left behind in the interop repo when the suite moved here, so the paths they cover — ingress filtering by content topic, causal ordering, late joiners, three-way fan-out and channel re-creation — are unguarded in this repo's CI. Bring them over: RC04 send-after-close, RC07 foreign content topic, RC08 bidirectional causal order, RC09 late-joining receiver, RC12 three participants, RC13 close/re-create then send. RC07 and RC08 get store off like every other channel test; the interop copies left the fixture default on, which pins an archive to the shared working directory for no reason of theirs. * test(e2e): port the RC10 parked-dependency test The CI-safe half of the SDS-R story: a receiver that never saw m1 must park m2 rather than deliver it out of causal order. Nothing here covered that, and it is the precondition the repair test builds on. Distinct-envelope matching is needed on the messaging layer because the send service rebroadcasts an unacknowledged message, and a rebroadcast is a fresh message_received carrying the same bytes. * test(e2e): port the SDS-R repair test behind a slow marker Closes the RC10 story the previous commit set up: B keeps sending until one of its messages carries the repair request, A rebroadcasts m1, and both messages land in causal order. Nothing else in this repo exercises SDS-R end to end. The test spends minutes waiting for T_req to elapse, so it gets a new slow marker and the PR selection deselects it. That leaves it with no automatic runner, which the README now says out loud. The interop copy deferred the receiver's stop_and_destroy through a finalizer to work around a teardown segfault; #4109 fixed that, and the test tears the node down in a with-block like its neighbours. * test(e2e): make RC08 actually check causal ordering As ported, the test proved nothing about causal order. It waits for each message to land before sending the next, so B seeing [m1, m3] follows from the test's own sequencing and would hold with causal history switched off entirely. It now checks the claim against the wire. When A sends m3 its SDS history holds m1 (sent) and m2 (received), so m3's envelope must reference m1's message id. The envelope is reachable: channel encryption is a noop, so the messaging-layer message_received event carries it verbatim — the same path `wire_payload` and RC10 already use. Ids are 64-char hex the minprotobuf embeds as-is, and the only other id-bearing field, the bloom filter, stores hashed bits. Mutating the expected id reddens the new assertion; the observed history is [m1, m2] as predicted. Renamed accordingly, and the settle constant no longer claims to be about causal history. RC13 carried the same overclaim twice over: a stray "causal order" in a failure message, and a docstring attributing its result to a restored SDS history that its assertions cannot distinguish from a fresh one. The overclaim came over verbatim from the interop suite, where it has been since the test was written.
tests-e2e — logos-delivery API/e2e tests (Python)
End-to-end tests for liblogosdelivery, driven through the Python bindings (C-FFI).
Migrated from logos-delivery-interop-tests (the wrapper / send-API suite).
Layout
src/— test framework (node wrappers, steps, helpers)tests/wrappers_tests/— the API/e2e scenario tests (test_s02…s31)vendor/logos-delivery-python-bindings/waku/wrapper.py— CFFI binding (NodeWrapper); itdlopens../lib/liblogosdelivery.so
Run locally
# 1. Build the shared library and place it where the binding looks for it
./tests-e2e/scripts/prepare_lib.sh
# 2. Python env + deps
python -m venv .venv && source .venv/bin/activate
pip install -r tests-e2e/requirements.txt
# 3. Run (from tests-e2e/)
cd tests-e2e
pytest tests/wrappers_tests -m "not docker_required and not slow" # 60 pure-binding tests, the CI selection
pytest tests/wrappers_tests -m docker_required # 5 tests that also need a Docker nwaku peer (S11/S19/S20/S25/S31)
pytest tests/wrappers_tests -m slow # 1 SDS-R repair test, minutes long
CI
.github/workflows/e2e-api-tests.yml (called from ci.yml, needs: build) downloads the
liblogosdelivery artifact produced by the build job and runs the non-docker subset on every PR —
so a protocol change and its e2e test land in the same PR.
The slow test is deselected there and there is no scheduled e2e job, so nothing runs it
automatically; run it by hand when touching SDS-R.