Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Flaky under load: actual_sdk_filters_notification_flood_before_handler_tasks

Open
#112 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
testing

Research direction

Start with the test actual_sdk_filters_notification_flood_before_handler_tasks in the bin target, run with cargo test --features mcp-test-client and its name as the filter. The Elapsed timeout is raised near src/mcp/transport.rs line 838, so read the wall-clock deadline there and the flood filter it exercises. Before settling on a fix, the maintainer's options (raise the deadline, assert on a counter or ordering, or serialize the test) need a decision. Done means the test passes reliably under load and still fails when the flood filter is removed.

Written by the indexing model from the issue text.

Description

bug effort/s impact/internal priority/p2 severity/medium triaged type/bug urgency/this-sprint

mcp::transport::tests::actual_sdk_filters_notification_flood_before_handler_tasks (bin target, --features mcp-test-client) fails intermittently when the machine is heavily loaded. On 2026-10-16 it failed during full local runs on at least four separate occasions. Load averages were around 80-280, with jobs and test threads capped at 4.

  • Most failures pass when the test is rerun alone. One reviewer saw it fail in isolation too, under the same load.
  • The failure is an Elapsed deadline timeout at src/mcp/transport.rs ~838.
  • CI has passed on every PR so far, but the local runs are unreliable for anyone checking a branch before pushing.

Suspect: the test's wall-clock deadline is too tight under CPU contention. This is the same class of problem as #97, the FIFO save test.

Options:

  • Raise the deadline. That loses some of what the test proves.
  • Base the assertion on a counter or an ordering rather than on elapsed time.
  • Mark the test as load-sensitive and serialize it.

Whichever fix is chosen, the test must still fail when the flood filter is removed.

Dominant language
Rust
Stars
4
Forks
2
Avg merge
2h 51m
Merged PRs (30d)
84

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cristim/AztecCraft

All issues in cristim/AztecCraft

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.