Repository navigation
Wire up test_features.rs — it currently never compiles or runs #522
Description
File: contracts/streaming/src/lib.rs:1309-1313, contracts/streaming/src/test_features.rs
Problem: mod test_features; is missing from the module list at the bottom of lib.rs (compare to bench/test/test_batch/test_integration/test_security, which are all declared). This means the entire test_features.rs file (605 lines, 26 #[test] fns covering event-field assertions, pause/unpause behavior, index optimization, stream-count accuracy) has never actually run — any "all tests passing" claim excludes it.
Task: Add mod test_features; to lib.rs, run cargo test, and fix whatever surfaces. Note: some of these tests call a partial_cancel() method that no longer exists on the contract (see H6) — those specific tests will need to be handled by H6, not this issue; everything else in the file should be made to pass on its own.
Activity
Markodiba6399 commentedon Aug 20, 2026
Hi, I'd like to take this.
The declaration itself is one line. The real work is whatever 605 lines of never-compiled tests produce on first run, and I can't scope that until I've run it. So my first step is to add mod test_features;, run cargo test -p streaming, and post the actual output here before opening a PR. That gives you a real picture rather than my guess at one.
What I'd expect to find, roughly in order of likelihood: compile errors from API drift, since a file that has never been compiled has had no pressure to keep up with signature changes in the contract; then assertion failures where the test encodes behaviour that has since changed; then, hopefully, some genuine bugs, which are the reason this issue is worth doing at all.
That last category is the one I'd handle carefully. When a test asserts something the contract doesn't do, the fix could be either direction, and a test that has never run carries no presumption of correctness. Event-field assertions and pause/unpause behaviour in particular are where I'd rather flag the discrepancy here and get a maintainer's read than unilaterally decide the test was wrong and adjust it to match current behaviour. Silently loosening assertions would technically satisfy "make them pass" while destroying the value of turning them on.
On the partial_cancel() tests: I'll leave those to H6 as instructed. If they're compile errors rather than runtime failures they'll block the whole module from building, so I'd need to #[ignore] or #[cfg(feature = ...)] them out temporarily with a comment pointing at H6, rather than deleting them. Let me know if you'd prefer a different holding pattern.
One thing worth checking while I'm in here: whether any other module is similarly undeclared. A missing mod line is invisible by nature, so if it happened once it may have happened twice.
grantfox-oss commentedon Aug 20, 2026
🦊 GrantFox — @Markodiba6399 has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #522)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 25, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@Markodiba6399's PR #625 was approved and merged by @Austinaminu2.
🏆 @Markodiba6399: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,185 total points). Track your full progress on GrantFox.
👏 Great work, @Markodiba6399! Keep contributing to FlowwStar.