Commit 00f7e4f
authored
fix: reporting race condition between flusher and syncer (#6585)
# Description
## Problem
This PR fixes a critical race condition in the reporting system that
causes metrics data loss when transactions take longer than expected to
commit.
### The Race Condition
The issue occurs due to timing between three operations:
1. **Report()** - Writing metrics to the database (with transaction
commit time)
2. **getReports()** - Reading and aggregating reports from a time bucket
3. **DELETE** - Removing processed reports after aggregation
### Data Loss Scenarios
#### Scenario 1: Data Deleted Before Commit Completes
If a `Report()` transaction (store stage) takes longer than the time
between `getReports()` + `mainLoop()` iteration but **shorter** than
reaching the DELETE operation:
1. Transaction starts writing metrics for minute bucket `T`
2. `getReports()` reads bucket `T` (doesn't see uncommitted transaction)
3. Transaction commits (data now in bucket `T`)
4. DELETE removes all data from bucket `T`
5. **Result: Metrics are deleted without ever being aggregated →
Complete data loss**
#### Scenario 2: Duplicate Send Causes Data Loss via Deduplication
If the store stage (commit) takes **longer** than even the DELETE
statement:
1. Transaction starts writing metrics for minute bucket `T`
2. `getReports()` reads bucket `T` (doesn't see uncommitted transaction)
3. Aggregated data sent to reporting service (without slow transaction
data)
4. DELETE removes data from bucket `T`
5. Transaction finally commits (data appears in bucket `T`)
6. Next `getReports()` reads bucket `T` again (now includes slow
transaction)
7. Data sent to reporting service again
However, the reporting service contract expects **minute level
aggregative data** and performs deduplication. When the same time bucket
is sent twice:
- First send: Missing the slow transaction's data
- Second send: Contains only the slow transaction's data
- **Result: Reporting service deduplicates and keeps only one, losing
the other → Partial data loss**
## Solution
This PR implements transaction tracking to ensure reports are only
flushed when safe:
1. **Track active transactions by time bucket** -
`activeTransactionsByReportedAt` map maintains a count of ongoing
transactions per minute bucket
2. **Block unsafe flushes** - `getReports()` checks if any active
transactions have `reportedAt < bucketEnd` before flushing
3. **Return specific error** - `errBlockedByActiveTransactions` signals
blocking without logging noise
4. **Lifecycle management** - Transaction counter incremented on start,
decremented on completion (via defer)
5. **New metric** -
`StatReportingMainLoopBlockedDueToActiveTransactionsCount` tracks
blocking frequency
### Key Implementation Details
- Mutex-protected concurrent access to transaction tracking map
- Defer ensures cleanup even on panics/early returns
- Non-intrusive error handling (doesn't spam logs for expected blocking)
- Proper cleanup (deletes map entry when count reaches 0)
## Linear Ticket
[PIPE-2679](https://linear.app/rudderstack/issue/PIPE-2679/reporting-race-condition-between-flusher-and-syncer)
## Security
- [ ] The code changed/added as part of this pull request won't create
any security issues with how the software is being used.1 parent b99eee6 commit 00f7e4f
3 files changed
+448
-11
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
31 | 31 | | |
32 | 32 | | |
33 | 33 | | |
| 34 | + | |
| 35 | + | |
34 | 36 | | |
35 | | - | |
36 | | - | |
37 | | - | |
38 | | - | |
39 | | - | |
40 | | - | |
41 | | - | |
42 | | - | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
43 | 46 | | |
44 | 47 | | |
45 | 48 | | |
| |||
74 | 77 | | |
75 | 78 | | |
76 | 79 | | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
77 | 83 | | |
78 | 84 | | |
79 | 85 | | |
| |||
134 | 140 | | |
135 | 141 | | |
136 | 142 | | |
| 143 | + | |
137 | 144 | | |
138 | 145 | | |
139 | 146 | | |
| |||
240 | 247 | | |
241 | 248 | | |
242 | 249 | | |
| 250 | + | |
| 251 | + | |
| 252 | + | |
| 253 | + | |
| 254 | + | |
| 255 | + | |
| 256 | + | |
| 257 | + | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
243 | 264 | | |
244 | 265 | | |
245 | 266 | | |
| |||
415 | 436 | | |
416 | 437 | | |
417 | 438 | | |
| 439 | + | |
418 | 440 | | |
419 | 441 | | |
420 | 442 | | |
| |||
452 | 474 | | |
453 | 475 | | |
454 | 476 | | |
455 | | - | |
| 477 | + | |
| 478 | + | |
| 479 | + | |
| 480 | + | |
| 481 | + | |
456 | 482 | | |
457 | 483 | | |
458 | 484 | | |
| |||
633 | 659 | | |
634 | 660 | | |
635 | 661 | | |
| 662 | + | |
636 | 663 | | |
| 664 | + | |
| 665 | + | |
| 666 | + | |
| 667 | + | |
| 668 | + | |
| 669 | + | |
| 670 | + | |
| 671 | + | |
| 672 | + | |
| 673 | + | |
| 674 | + | |
| 675 | + | |
| 676 | + | |
| 677 | + | |
| 678 | + | |
| 679 | + | |
| 680 | + | |
637 | 681 | | |
638 | 682 | | |
639 | 683 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3 | 3 | | |
4 | 4 | | |
5 | 5 | | |
6 | | - | |
| 6 | + | |
| 7 | + | |
7 | 8 | | |
8 | 9 | | |
9 | 10 | | |
| 11 | + | |
| 12 | + | |
10 | 13 | | |
11 | 14 | | |
12 | 15 | | |
13 | 16 | | |
14 | 17 | | |
15 | 18 | | |
16 | 19 | | |
17 | | - | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
18 | 35 | | |
19 | 36 | | |
| 37 | + | |
20 | 38 | | |
21 | 39 | | |
22 | 40 | | |
23 | 41 | | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
| 48 | + | |
24 | 49 | | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
25 | 77 | | |
26 | 78 | | |
0 commit comments