e2e-image-path's leecher step proves the bytes arrived. It does not prove they arrived the way the lane's infrastructure claims.
Evidence
run-leecher/action.yml waits for the seeder Deployment to go Available, fetches the .torrent, calls ezio's AddTorrent, polls until finished, and byte-compares against the fixture. No step reads the tracker's scrape output or its log. The failure-path diagnostics dump the Service and Endpoints objects, which show the tracker is routable, not that it was used.
The lane runs single-node RKE2 with Multus disabled, so the seeder pod and the leecher pod share one local bridge.
tmp/ezio/app.cpp's make_session_params never sets enable_lsd or enable_dht, so libtorrent's defaults apply and both are on.
The scenario where the lane passes and the claim is false
Both pods land on the same node, which is certain on a single-node cluster. Local Service Discovery multicast lets the leecher find the seeder with no announce ever reaching the tracker. The swarm still works, the bytes are still correct, and the byte-compare still passes.
Scope
Confirmed at the mechanism level: the code and the topology were both checked. Whether it happens on any given run needs a tracker log or a packet capture, which this lane does not collect.
Same root cause as #37.
Suggested fix
Read the tracker's scrape for the run's info hash before declaring the leech successful, or collect the tracker log as an artifact so a reader can tell after the fact.
e2e-image-path's leecher step proves the bytes arrived. It does not prove they arrived the way the lane's infrastructure claims.Evidence
run-leecher/action.ymlwaits for the seeder Deployment to go Available, fetches the.torrent, calls ezio'sAddTorrent, polls until finished, and byte-compares against the fixture. No step reads the tracker's scrape output or its log. The failure-path diagnostics dump the Service and Endpoints objects, which show the tracker is routable, not that it was used.The lane runs single-node RKE2 with Multus disabled, so the seeder pod and the leecher pod share one local bridge.
tmp/ezio/app.cpp'smake_session_paramsnever setsenable_lsdorenable_dht, so libtorrent's defaults apply and both are on.The scenario where the lane passes and the claim is false
Both pods land on the same node, which is certain on a single-node cluster. Local Service Discovery multicast lets the leecher find the seeder with no announce ever reaching the tracker. The swarm still works, the bytes are still correct, and the byte-compare still passes.
Scope
Confirmed at the mechanism level: the code and the topology were both checked. Whether it happens on any given run needs a tracker log or a packet capture, which this lane does not collect.
Same root cause as #37.
Suggested fix
Read the tracker's scrape for the run's info hash before declaring the leech successful, or collect the tracker log as an artifact so a reader can tell after the fact.