Files
Andrey Vasnetsov c16c55b1fc Bump client timeout in flaky snapshots-consensus e2e test (#9808)
TestSnapshotsInterferenceWithConsensus flakes when the initial
create_collection exceeds the 10s client read timeout. Cluster logs
from a failing run show the primary stalling its consensus loop for
~5s while creating local shards on a loaded runner, which triggered
a leader election that delayed full shard activation to ~10.3s.

Setup operations now get a 30s client timeout. The regression check
for #7489 is unaffected: it relies on the server-side operation
timeout passed to delete_collection, not the client read timeout.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 21:14:04 +02:00
..
2026-05-19 15:01:15 +02:00
2025-10-21 14:05:57 +02:00
2025-10-08 12:50:34 +02:00
2026-03-31 18:08:39 +00:00

TLS test

Regenerate certificates

  1. run PROJECT_ROOT/tests/e2e_tests/test_data/gen.sh
  2. replace old certificates in PROJECT_ROOT/tests/e2e_tests/test_data/cert with the newly generated ones

Data compatibility test

In order to detect quickly breakage of storage compatibility, we check that the current code understands the storage format from the latest stable release.

To not burden the git repository with tracking the large binary files, we are pushing storage archives to our GCP bucket.

As features are added, the storage format may change. This means updating the reference storage data and snapshot. This is done by running the gen_storage_compat_data.sh script.

Regenerate storage data

Follow those steps to recreate the reference storage data and snapshot.

  1. run PROJECT_ROOT/tests/e2e_tests/test_data/compatibility/gen_storage_compat_data.sh
  2. make sure to pick the right version when asked for which system generated the files
  3. push the new archives to the GCP bucket (ask for the credentials if you don't have them)