MettaChain/PropChain-contract

Re-enable bridge load tests with deterministic isolation

Geschlossen

#755 geöffnet am 23.07.2026

Auf GitHub ansehenContributor Guide
 (4 Kommentare) (0 Reaktionen) (1 zugewiesene Person)Rust (151 Forks)auto 404
High ComplexityRustStellar Wavebughelp wantedperformancetesting

Repository-Metriken

Stars
 (1 Stern)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

Problem Statement

tests/bridge_load_tests.rs:226 and tests/integration_bridge_oracle.rs have #[ignore] due to test isolation.

Why it matters

Load tests are the empirical basis for our gas-budget claims; if they're ignored, we have no load signal.

Technical Context

Fix the isolation (#39) then unignore; rewrite load assertions to be deterministic (use Instant::now of mocked env, not wall-clock).

Expected Outcome

Full suite runs in CI; ≥ 10k requests in < 10s documented in result.

Acceptance Criteria

  1. cargo test --release load_test_concurrent_registration_light green.
  2. cargo test --release stress_test_mass_registration green.
  3. Output captured to docs/PERFORMANCE.md.

Implementation Notes

Use per-test Arc<Mutex<…>> harness with set_block_number(0) reset.

Files or modules likely to be affected

tests/bridge_load_tests.rs, tests/integration_bridge_oracle.rs.

Dependencies

#39.

Difficulty level

HARD.

Estimated effort

M (~3 days).

Contributor Guide

Research-Richtung
Untersuchen Sie den Isolationsfehler in tests/bridge load tests.rs und tests/integration bridge oracle.rs, implementieren Sie deterministische Isolation mit einem Arc<Mutex> Harness mit set block number(0) Reset, schreiben Sie die Last Assertions um, um Instant::now aus der gemockten Umgebung zu verwenden, und führen Sie dann cargo test release aus, um zu überprüfen, dass load test concurrent registration light und stress test mass registration grün sind.
Tech Stack
rust
Domain
backendtesting
Issue Type
Test
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
4
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
3-5 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
RustCargoTesting
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
40