tests: Add zombienet test for bitswap_v1_get by BigTava · Pull Request #3240 · paritytech/smoldot

BigTava · 2026-04-30T16:03:57Z

…p-get

BigTava · 2026-04-30T17:01:51Z

@skunert you mention snapshots should live on Google Drive, but I haven't seen anything similar. polkadot-bulletin-chain stores its build outputs as GitHub artifacts (e.g. release.yml#L98-L103). Should we do that instead?

skunert · 2026-05-04T08:25:09Z

@BigTava An example can be seen here: https://github.com/paritytech/polkadot-sdk/blob/3501f2c3c8e46d0b726994065a05615995f03880/cumulus/zombienet/zombienet-sdk/tests/zombie_ci/full_node_warp_sync/common.rs#L26

I think artifacts can be of limited size only and have a retention period. These snapshots we should only generate very rarely and then always reuse.

skunert · 2026-05-04T08:27:33Z

Hmm looks like I lost access to our cloud storage, @pepoviola what is the current way to store these snapshots, do you still have access?

pepoviola · 2026-05-04T09:34:32Z

Hmm looks like I lost access to our cloud storage, @pepoviola what is the current way to store these snapshots, do you still have access?

You should have access to zombienet-db-snaps bucket, let me know if doesn't works for you and I can re-check.
Thx!

Snapshots live in the zombienet-db-snaps bucket under smoldot/bulletin_fetch/, accessed via hardcoded URLs that with_db_snapshot() downloads automatically. Local override is wired through DB_SNAPSHOT_*_OVERRIDE env vars. Drops the manifest.json read on the fetch path: payload metadata is derived from bulletin::payloads() at runtime instead.

Renamed to bulletin::payloads() in the code earlier; README missed it.

BigTava · 2026-05-04T16:54:43Z

An example can be seen here

Thanks @skunert! I added the remaining code based on this example. The snapshots come out to ~50 MB total. Someone with bucket-write access needs to upload them for the CI job to pass.

lrubasze

Nice work!
Few comments from my side

The DB_SNAPSHOT_* constants now point at -2026-05-04.tgz so the bucket keeps a clear version history instead of silently overwriting on each refresh. Bump the date in the constants (and re-upload) whenever the bulletin runtime or bulletin::payloads() changes.

- Mixed-availability scenario now iterates every full-only payload instead of only the first match, so both 31 B and 1 MiB cases exercise gossip fallback. - Rename payload labels to `all-nodes-*` / `one-node-*` so they describe corpus location instead of opaque `both-*` / `full-only-*`. - Hoist `RELAY_CHAIN`, `RELAY_BINARY`, `PARA_BINARY` into `bulletin.rs`; both test files reference the shared consts. - Trim the `bitswapGetWithRetry` doc to a single line. - `cargo fmt`.

The bare `sendRpcAndWait` was relying on the implicit ordering that prior `known-*` scenarios had already warmed up smoldot. Wrap this call too so the assertion is robust to test reordering and cold-start hangs. `-32602` propagates on the first attempt anyway, so behaviour in the happy path is unchanged.

…p-get

michalkucharczyk · 2026-05-07T09:07:41Z

Dumb question: does e2e-tests/tests/bulletin_generate_snapshot.rs really belongs to smoldot repo domain?

I can imagine such snapshot can be used for bulletin related functionality also in other repos.
And one more thought - should snapshot generation be part of zombienet sdk? Again I can imagine this code will be duplicated in every test that requires snapshot (cc: @pepoviola).

@lrubasze @skunert - does it feel right for you?
@karolk91 wdyt?

lrubasze · 2026-05-07T09:23:16Z

Dumb question: does e2e-tests/tests/bulletin_generate_snapshot.rs really belongs to smoldot repo domain?

I can imagine such snapshot can be used for bulletin related functionality also in other repos. And one more thought - should snapshot generation be part of zombienet sdk? Again I can imagine this code will be duplicated in every test that requires snapshot (cc: @pepoviola).

@lrubasze @skunert - does it feel right for you? @karolk91 wdyt?

I think this is fine.
We use similar approach in full_node_warp_sync test

Tests that use snapshot and test that generates it need to have the same network setup. So i think it is good to keep them in one place. Unless we outsource zombienet network setup too.

…p-get

skunert · 2026-05-07T09:49:40Z

should snapshot generation be part of zombienet sdk?

I thought about this in the past too, my 2c is that its okay to include this per-repo, because sometimes the snapshots need to replicate specific scenarios. For bulletin I can imagine scenarios with specific counts of renew/store tx etc.

BigTava · 2026-05-07T10:11:26Z

@lrubasze @skunert needs 2 approvals. Thanks

skunert

Nice!

skunert · 2026-05-07T10:21:32Z

+    );
+  }
+
+  for (const payload of payloads.filter((p) => !p.on_partial)) {


One nit (don't think we need to change it right now). Would be nice to know if we actually hit the partial case where a CID is unavailable. Imagine if peer switching was broken and smoldot would always ask the same peer, then this test would become flaky depending on which peer is chosen for request right? Not sure we have a good way to handle this case currently.

Smoldot handles DontHave silently in bitswap_service.rs, so there was nothing for the test to scrape today. Feel free to file that as a follow-up issue to discuss and implement.

Avoids matrix-slot collision with PR #3242 (more smoke tests), which takes 0004-0006.

pepoviola · 2026-05-07T13:42:11Z

should snapshot generation be part of zombienet sdk?

I thought about this in the past too, my 2c is that its okay to include this per-repo, because sometimes the snapshots need to replicate specific scenarios. For bulletin I can imagine scenarios with specific counts of renew/store tx etc.

I aggre, but we can offload the creation logic to zombienet-sdk itself, so per repo you only need to setup the network and call something like network.generate_snap(). I will add a new issue to track this in zombienet repo.

Thx!

BigTava added 2 commits April 30, 2026 16:43

e2e-tests: Add zombienet test for bitswap_v1_get

404b16b

Closes #3232

Merge remote-tracking branch 'origin/main' into tiago-e2e-test-bitswa…

d04d9aa

…p-get

BigTava marked this pull request as draft April 30, 2026 16:56

BigTava marked this pull request as ready for review April 30, 2026 16:56

BigTava changed the title ~~e2e-tests: Add zombienet test for bitswap_v1_get~~ tests: Add zombienet test for bitswap_v1_get Apr 30, 2026

skunert requested review from lrubasze and michalkucharczyk May 4, 2026 08:27

BigTava added 3 commits May 4, 2026 17:23

e2e-tests: Fix stale "corpus" reference in README

3e87ad1

Renamed to bulletin::payloads() in the code earlier; README missed it.

ci: Add bulletin_fetch to the zombienet matrix

c79cc07

lrubasze reviewed May 4, 2026

View reviewed changes

Comment thread e2e-tests/js/bulletin_fetch.js Outdated

Comment thread e2e-tests/src/bulletin.rs Outdated

Comment thread e2e-tests/tests/bulletin_fetch.rs Outdated

Comment thread e2e-tests/js/bulletin_fetch.js

Comment thread e2e-tests/js/bulletin_fetch.js Outdated

BigTava and others added 5 commits May 5, 2026 17:30

Merge branch 'main' into tiago-e2e-test-bitswap-get

7e89549

Merge remote-tracking branch 'origin/main' into tiago-e2e-test-bitswa…

13f2385

…p-get

lrubasze approved these changes May 7, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into tiago-e2e-test-bitswa…

50f5af6

…p-get

BigTava requested a review from lrubasze May 7, 2026 10:11

lrubasze approved these changes May 7, 2026

View reviewed changes

skunert approved these changes May 7, 2026

View reviewed changes

ci: Renumber bulletin_fetch job to 0007

62a0a7c

Avoids matrix-slot collision with PR #3242 (more smoke tests), which takes 0004-0006.

BigTava merged commit d4b786c into main May 7, 2026
33 checks passed

BigTava deleted the tiago-e2e-test-bitswap-get branch May 7, 2026 11:58

Conversation

BigTava commented Apr 30, 2026

Uh oh!

BigTava commented Apr 30, 2026

Uh oh!

skunert commented May 4, 2026

Uh oh!

skunert commented May 4, 2026

Uh oh!

pepoviola commented May 4, 2026

Uh oh!

BigTava commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lrubasze left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

michalkucharczyk commented May 7, 2026

Uh oh!

lrubasze commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skunert commented May 7, 2026

Uh oh!

BigTava commented May 7, 2026

Uh oh!

skunert left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

skunert May 7, 2026

Choose a reason for hiding this comment

Uh oh!

BigTava May 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pepoviola commented May 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

BigTava commented May 4, 2026 •

edited

Loading

lrubasze commented May 7, 2026 •

edited

Loading