fix: stop dropping the bytes between the chunk boundary and the read size - #396
Open
arpitjain099 wants to merge 1 commit into
Open
fix: stop dropping the bytes between the chunk boundary and the read size#396arpitjain099 wants to merge 1 commit into
arpitjain099 wants to merge 1 commit into
Conversation
…size ReadChunk consumes up to size+maxPeekSize bytes from the reader, then generateChunk stops at the first safe "\n\n" boundary it finds past the chunk size and returns only that prefix. Everything the read consumed after the boundary is thrown away, and the next call starts from wherever the reader now sits, so that content is never scanned. Peek instead of Read and Discard exactly the bytes the chunk covers, which is what the maxPeekSize name implies. Both call sites already size the bufio.Reader as size+maxPeekSize, and ErrBufferFull is tolerated so a smaller reader degrades to a short look-ahead instead of failing. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed Changes
ReadChunkreads up tosize + maxPeekSizebytes out of the reader, andgenerateChunkthen walks forward fromsizelooking for a safe\n\nsplit. When it finds one it breaks and returns the prefix. The bytes that the read already consumed after that split are dropped on the floor. The nextReadChunkcall starts from where the reader is now, which is past them, so that content never reaches the detectors.Both loops (
engine.go:337for filesystem,plugins/confluence.go:370for Confluence pages) callReadChunkin a loop untilio.EOF, so the gap is silent. Nothing errors, the scan just does not cover part of the file.With a chunk size of 10 and a peek size of 5, scanning
"0123456789\n\nSECRET\n"gives:"SEC" is gone. At the shipped defaults the window is 100KiB/25KiB, so any file over 100KiB can lose up to 25KiB per chunk, and a secret sitting in that region is not scanned.
The fix is to
Peekrather thanRead, andDiscardexactly the number of bytes the returned chunk covers. That is what the "look-ahead" naming already implies. Both call sites build the reader withbufio.NewReaderSize(..., GetSize()+GetMaxPeekSize()), so the peek fits;bufio.ErrBufferFullis tolerated anyway, which means a caller with a smaller reader degrades to a shorter look-ahead instead of erroring.Error behaviour is unchanged: empty input still returns
io.EOF, and the unsupported-file-type check still runs on the first read with the same window of bytes.Side note:
GetPeekedBuf/PutPeekedBufandpeekedBufPoolare no longer used byReadChunk. I left them in place since they are exported and covered by tests. Happy to remove them if you would rather not carry them.Checklist
TestReadChunkKeepsEveryBytereads a source to EOF and compares the concatenation of every chunk against the input. It fails on master for two of its three cases and passes with this change.go test ./engine/... ./plugins/...is green, andgofmtis clean.I submit this contribution under the Apache-2.0 license.