Resolve "ConsistencyWorker exceeds 300 seconds"

Related to #360918 (closed)

The ConsistencyWorker now passes down to the ConsistencyCheckService an instance of a new RuntimeLimiter class, so that the service can check before processing each batch of events if it ran out of time. If so, ConsistencyCheckService returns early with some cursor data, which the ConsistencyWorker saves on the Aggregation model, so that the next run can start from where the previous run stopped.

The cursor data is persisted in the following columns on the Aggregation model (we need the same column for Issues and MergeRequests):

last_consistency_check_issues_stage_event_hash_id
last_consistency_check_issues_start_event_timestamp
last_consistency_check_issues_end_event_timestamp
last_consistency_check_issues_issuable_id

last_consistency_check_merge_requests_stage_event_hash_id
last_consistency_check_merge_requests_start_event_timestamp
last_consistency_check_merge_requests_end_event_timestamp
last_consistency_check_merge_requests_issuable_id

Note that, for consistency, also the other cycle analytics workers were refactored to use RuntimeLimiter.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Magdalena Frankiewicz

Merge request reports

Loading