Repository navigation
fix: a replay with short waits between events no longer stalls after the first one - #403
Conversation
…the first one _dispatch_next sent one event and then re-added its own APScheduler job for the next. When the wait was zero or shorter than what was left of the running job, the new run came due while that job still counted as running, so APScheduler skipped it under max_instances=1 and nothing scheduled another: the session sat in running with one event sent. One job now loops over the events and awaits each wait itself. Pause and cancel stop it through the status check, as before.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
Codecov Report❌ Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes
🚀 New features to boost your workflow:
|
…their own methods (#405) SonarCloud failed #403 on python:S3776: wrapping the old dispatch body in a loop put _dispatch_events at cognitive complexity 21 against the allowed 15. _next_event loads the next batch when the loaded one runs out, and _dispatch_event sends one event and returns the wait before the next; the loop only joins them. Behaviour is the same.




Summary
Small bug found while checking the replay metrics in #401: a replay session whose next event is due at once, or within a few milliseconds, stops after one event and stays
running. That covers every replay at speed 100 and anything replaying events with equal or very close timestamps. Locally a 30-event session at speed 100 sat atrunningwith 1 event sent, and the scheduler logged "skipped: maximum number of running instances reached (1)".Changes
_dispatch_nextsent one event and then added its own APScheduler job again for the next one. When that run came due while the current run still counted as running, APScheduler skipped it, and nothing scheduled another. Now one job,_dispatch_events, loops over the events and awaits each delay itself. Pause and cancel stop it through the status check as before. A resume that lands while the loop still waits is skipped by the same rule, and the loop carries on.Type of Change
Test Plan
cd backend && uv run pytest tests/unit)cd frontend && npm run test)docker compose exec -T backend sh -c 'uv sync --group test --no-dev --frozen --no-install-project --no-build && pytest tests/e2e')cd frontend && npm run test:e2e)./deploy.sh openapi, then./deploy.sh types), never edited by handValidation: the new test replays 25 events at speed 100 and 99 through
start_sessionand times out on main's code; with the fix it passes. Unit 572 passed, e2e 488 passed and 1 skipped. The 30-event session at speed 100 now completes in 0.055 s.Checklist
pre-commit run --all-filesand all checks passSummary by cubic
Fixes replay sessions stalling after the first event when waits between events are zero or within a few milliseconds, which covers every replay at speed 100 and any session with equal or very close event timestamps.
max_instances=1and nothing scheduled another, leaving the sessionrunningwith one event sent._dispatch_events, now loops over the events and awaits each delay itself.Written for commit 79d41f9. Summary will update on new commits.