test: Fix flaky test_request_reclaim_functionality[shared] integration test

[vdusek]

Summary

• Add retry logic to fetch_next_request() calls in test_request_reclaim_functionality to handle propagation delays in shared request queue access mode
• The [shared] variant was flaky because newly added or reclaimed requests may not be immediately visible
• Introduces a _fetch_next_request_with_retry() helper that polls up to 10 times with 1-second intervals

Test plan

• CI integration tests pass consistently for both [single] and [shared] variants

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.43%. Comparing base (e1bdbc9) to head (4260b08).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #803      +/-   ##
==========================================
- Coverage   85.47%   85.43%   -0.04%     
==========================================
  Files          46       46              
  Lines        2691     2691              
==========================================
- Hits         2300     2299       -1     
- Misses        391      392       +1     

Flag	Coverage Δ
e2e	35.48% <ø> (?)
integration	57.59% <ø> (-0.04%)	⬇️
unit	72.38% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[janbuchar]

Since the integration test shows intended usage, I think we're not actually fixing anything. We're just sweeping an issue under the rug.

In other words, this is not a flaky test, this shows the code under test being unreliable.

[vdusek]

Yes, but how can we handle this in the case of a shared client? 🙂 If I understand it correctly, a single client adds requests directly to the local queue_head deque, which makes them immediately available. However, a shared client can't do that, right? If retries aren't an option, I'd suggest skipping this test for the shared client for now, opening an issue, and keeping it skipped until we resolve it somehow.

[janbuchar]

I guess either skip it or add a well-aimed if mode == "shared": sleep(). That's probably more upfront about what we're dealing with.