Repository navigation
Allocate history job IDs atomically - #928
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #928 +/- ##
==========================================
+ Coverage 72.90% 72.96% +0.05%
==========================================
Files 182 182
Lines 36127 36144 +17
Branches 2532 2532
==========================================
+ Hits 26337 26371 +34
+ Misses 8885 8868 -17
Partials 905 905 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Draft decision required (renewed review) A persistence owner must define how the atomic counter is bootstrapped above job IDs already stored by legacy deployments, including explicit-ID behavior. Fresh-database concurrency tests are insufficient; this PR stays draft until a migration or namespace policy guarantees global uniqueness. |
|
Review status: Draft. Required code fix: validate every explicit job ID as a non-bool integer before any Mongo operation; invalid BSON values can otherwise mutate and corrupt the numeric counter. Deployment decision: use an idempotent one-time bootstrap to the maximum legacy |
f75af90 to
b7263fc
Compare
|
Review decision: ready after final CI. Runtime allocation uses one atomic counter and never scans legacy history. Legacy high-water initialization is explicit and idempotent; explicit IDs reserve the counter, and invalid ID types fail before database access. The branch now contains only the three #782 commits rebased on current master. |
Summary
Closes #782