goQuery might panic if corrupt block is detected

[fako1024]

If a error is encountered during block parsing:

ts=2024-04-19T10:12:35.855+02:00 level=warn msg="Failed to read column: decompression failed: (errno -194)" version=devel day="&{gpFiles:[0xc0001cf760 0xc0001cfb80 <nil> <nil> 0xc0001cfc30 0xc0001cfce0 0xc0001cfd90 0xc0001cfe40] options:[0x6edc00 0x6f04e0] basePath:/shared/data/OSAGtmi/db/eth40 dirPath:/shared/data/OSAGtmi/db/eth40/2024/04/1713398400 metaPath:/shared/data/OSAGtmi/db/eth40/2024/04/1713398400/.blockmeta accessMode:0 permissions:420 isOpen:true Metadata:0xc000701680}" block=1713428700 column=sip
ts=2024-04-19T10:12:35.855+02:00 level=warn msg="Incorrect number of entries in variable block size file. Expected file length -936, have 0" version=devel block=101 column=sip

it seems that processing still continues and attempts to decompress the (corrupted) bitpacked data, which in turn leads to a panic (addressed in https://github.com/fako1024/gotools/issues/1):

panic: runtime error: integer divide by zero

goroutine 69 [running]:
github.com/fako1024/gotools/bitpack.Len(...)
    /home/rpm/go/pkg/mod/github.com/fako1024/gotools/bitpack@v0.0.0-20230905084243-56aa6a34fb53/bitpack.go:114
github.com/els0r/goProbe/pkg/goDB.(*DBWorkManager).readBlocksAndEvaluate(0xc0000a1860, 0xc00016be00, {0xfad700, 0xc0003beae0}, 0xc0018bdeb8)
    /usr/src/packages/src/sdwan/security/pkg/OSAGtmi/goProbe/pkg/goDB/DBWorkManager.go:580 +0x251c
github.com/els0r/goProbe/pkg/goDB.(*DBWorkManager).grabAndProcessWorkload.func1()
    /usr/src/packages/src/sdwan/security/pkg/OSAGtmi/goProbe/pkg/goDB/DBWorkManager.go:493 +0x545
created by github.com/els0r/goProbe/pkg/goDB.(*DBWorkManager).grabAndProcessWorkload in goroutine 1
    /usr/src/packages/src/sdwan/security/pkg/OSAGtmi/goProbe/pkg/goDB/DBWorkManager.go:452 +0xbd

Regardless of the upstream issue in bitpack the DBWorkManager.go shouldn't even continue if such error is encountered.

DoD

• [x] Cross-check flow and identify affected scenarios
• [x] Abort processing block if an error is encountered
• [x] Improve log output (day="&{gpFiles:[0xc0001cf760 ... is not helpful)

[fako1024]

Easy as pie: We break the initial loop if the column is broken, but we still continue :weary:

// Read the blocks from their files
for _, colIdx := range w.query.columnIndices {

    // Read the block from the file
    if blocks[colIdx], err = workDir.ReadBlockAtIndex(colIdx, b); err != nil {
        blockBroken = true
        logger.With("day", workDir, "block", block.Timestamp, "column", types.ColumnFileNames[colIdx]).Warnf("Failed to read column: %s", err)
        break
    }
}

// We happily continue...