Jackie-Jiang opened a new pull request, #19292:
URL: https://github.com/apache/pinot/pull/19292

   ## Summary
   
   The pauseless recovery tests shorten the max segment completion time to 10 
seconds so that segments stranded by an injected failure become eligible for 
repair after a short sleep. The shortened window applies to every segment 
though, so on a slow CI runner it also kills perfectly healthy commits: any 
segment whose commit-end arrives more than 10 seconds after its commit-start 
metadata update is permanently rejected with `Exceeded max segment completion 
time`, stays `COMMITTING` with no download URL, and — since recovery in these 
tests is a single manually triggered validation run — nothing ever repairs it. 
This matches the observed CI failure signature: `testSegmentAssignment` (which 
injects no failure and never runs the validator) timing out with "Some segments 
have status COMMITTING", and the failure scenarios timing out with "Some 
segments still have missing url".
   
   Replace the shortened window with explicit force-expiry of the stranded 
segments:
   - `FailureInjectingPinotLLCRealtimeSegmentManager` keeps a set of 
force-expired segment names; `isExceededMaxSegmentCompletionTime` returns true 
for those and otherwise defers to the production logic with the default 
5-minute window. The `setMaxSegmentCompletionTimeoutMs` override is removed.
   - The recovery flows 
(`BasePauselessRealtimeIngestionTest#runValidationAndVerify` and 
`PauselessRealtimeIngestionSegmentCommitFailureTest#verifyRecovery`) disable 
the injected failure, snapshot the table's current segments and force-expire 
them, trigger the single validation run, then clear the expiry.
   
   Effects:
   - The 10-second `Thread.sleep` before each validation run is gone — repair 
eligibility is immediate.
   - Happy-path commits (the no-failure scenario, the reference tables, 
force-commits during rebalance) run under the production completion time and 
can no longer be stranded by a slow runner.
   - The recovery semantics stay strict: while the expiry is active, in-flight 
commit attempts for the stranded segments keep getting rejected, so the single 
validation run remains the only recovery path under test. Clearing the expiry 
right after the run lets segments re-activated by the repair (e.g. in the 
ideal-state-update-failure scenario) commit normally.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to