Allow for mark == bytes.length in SlicedInputStreamTests#128340
Allow for mark == bytes.length in SlicedInputStreamTests#128340prdoyle merged 1 commit intoelastic:mainfrom
Conversation
In the case that the mark is at the very end of the stream, the slice's stream could already be closed by the time we call reset(), and so the stream must be reopened.
elasticsearchmachine
added
needs:triage
prdoyle
added
>test
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
prdoyle
changed the title
ldematte
added
the
:Distributed/Snapshot/Restore
elasticsearchmachine
added
the
Team:Distributed Coordination (obsolete)
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
In the case that the mark is at the very end of the stream, the slice's stream could already be closed by the time we call reset(), and so the stream must be reopened.
💚 Backport successful
|
|
@kingherc - I'm not totally confident I've identified the root cause, or that my fix covers all cases. For example, it doesn't cover the case that the mark is at the end of a slice other than the last slice. But at least the particular failure I observed won't happen anymore. |
|
Great catch @prdoyle !
Just run the test with mark = end, and indeed the test was failing due to that. Debugging it, it seems that I don't believe it can happen at the end of an intermediate slice, as if a stream is ending, it's because there's a read of a byte, and that means we'll keep opening streams until we read at least a byte (thus making currentSliceOffset non-zero) or reaching the end of the bytes. So indeed it seems you caught the corner case, thanks! |
5 participants
Background
I saw this error on a build on commit 4faef72:
Hypothesis
In the case that the mark is at the very end of the stream, the slice's stream could already be closed by the time we call
reset(), and so the stream must be reopened.Test fix
Change the test so the above assertion passes whenever the
markis right at the end of the input.