FANNG1 commented on issue #67026:
URL: https://github.com/apache/doris/issues/67026#issuecomment-5376523534

   Correction: I can no longer reproduce this, so the "deterministic" 
characterisation above is wrong and I want to flag that before anyone spends 
time on it.
   
   What I have now, on the same machine and the same docker environment:
   
   - `test_lance_vector_search` passes, three times in a row — once as part of 
`-d external_table_p0/lance` (all 7 suites green, including 
`test_lance_vector_search_two_phase`) and twice run on its own.
   - The `boundary_single_probe` result now matches the golden, i.e. neighbours 
on both sides of the query point.
   
   What changed in between was FE/BE rebuilds and process restarts, plus an 
unrelated FE-side refactor of mine that cannot affect the search path. Nothing 
touched the fixture datasets or the index.
   
   So the accurate statement is: the failure was real and reproduced four 
times, including on a clean build of `5dcf1066af4` with none of my changes 
present, and then stopped reproducing after rebuilding and restarting. That 
makes it **state-dependent rather than deterministic**, and I do not know what 
the trigger is — the earlier runs were stable enough (byte-identical output 
across three runs) that it did not look like ordinary flakiness at the time.
   
   Two things still stand and are why I am leaving this open rather than 
closing it:
   
   - When it did fail, the returned candidate set was one-sided (`row_id >= 
256` only), which is a search-result difference and not a golden-ordering nit.
   - It reproduced without any of my changes, so whatever the trigger is, it is 
not specific to #66805.
   
   @zhangstar333 — sorry for the noise. If this does not ring a bell as a known 
state-dependent behaviour in the distributed search path, it is probably not 
worth chasing on my report alone, and I am happy for this to be closed. I will 
reopen with a proper reproduction if I hit it again.
   


-- 
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