Commit 0546e04
committed
fix(e2e): wait for pi compartment_in_progress to clear after publish
CI run 26104810358 caught a pre-existing race in the Pi historian
success-path test: the compartment row appears the moment historian's
publish transaction commits, but `compartment_in_progress` is cleared
in the runner's `finally` block AFTER all post-publish work (memory
promotion, drop queueing, compaction marker, compressor pass). On
shared GitHub runners that gap can stretch beyond the 300ms initial
sleep, so the assertion fires while the flag is still 1.
The fix wraps the second assertion in a `waitFor` polling the same
flag with a 60s timeout. The seeing-the-row check already uses
`waitFor`; this just extends the same pattern to the in-progress flag
that lands later in the same code path.
Not a production regression — it's the test's wait window that's too
short, not the runner.1 parent 9447279 commit 0546e04
1 file changed
Lines changed: 20 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
162 | 162 | | |
163 | 163 | | |
164 | 164 | | |
| 165 | + | |
| 166 | + | |
| 167 | + | |
| 168 | + | |
| 169 | + | |
| 170 | + | |
| 171 | + | |
| 172 | + | |
| 173 | + | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
| 179 | + | |
| 180 | + | |
| 181 | + | |
| 182 | + | |
| 183 | + | |
| 184 | + | |
165 | 185 | | |
166 | 186 | | |
167 | 187 | | |
| |||
0 commit comments