Does job reset drop commands if sent in quick succession? #548

Activity

1. SimonHeybrock

   added

   bug

   on Nov 24, 2025
2. SimonHeybrock

   added a commit that references this issue on Nov 25, 2025

   Add regression tests for issue #548 (job reset race condition)

   ...

   b0d15bc
3. SimonHeybrock commented on Nov 25, 2025

   

   SimonHeybrock

   on Nov 25, 2025

   Last edited by SimonHeybrock

   MemberAuthor

   More actions

   Investigation Summary

   I investigated this issue but could not reproduce the bug. The code correctly handles multiple job reset commands sent in rapid succession.

   What was checked

   1. ConfigProcessor deduplication logic (config_handler.py): Groups messages by (config_key, source_name). Since each job has a unique source_name (derived from str(job_id)), different jobs are NOT deduplicated against each other.

   2. JobManager.reset_job: Correctly handles resetting individual jobs without shared state issues.

   3. KafkaSink.publish_messages: Uses unique Kafka keys for each job command and calls flush() after publishing.

   Tests added

   Branch: issue-548-investigation

   • Unit tests verifying ConfigProcessor correctly processes multiple job commands for different jobs
   • Unit test for JobManager resetting multiple jobs in succession
   • Integration tests (with Kafka, 10 iterations each):
     • test_rapid_reset_same_job_multiple_times - Sends 3 resets to same job rapidly
     • test_reset_two_different_sources - Resets jobs for monitor1 and monitor2 rapidly

   All tests pass consistently.

   Questions

   • How was "only one restarted" observed? (UI status? Logs? Data output?)
   • Is it still reproducible?
4. SimonHeybrock

   added the

   Bug

   issue type on Nov 28, 2025
5. SimonHeybrock

   removed

   bug

   on Nov 28, 2025
6. SimonHeybrock commented on Mar 2, 2026

   

   SimonHeybrock

   on Mar 2, 2026

   MemberAuthor

   More actions

   Closing unless reported again.
7. SimonHeybrock

   closed this as completedon Mar 2, 2026