next is red: queue_depth.go calls (*gorm.DB).Scan, tripping the scan guard #235

New Issue

2026-08-20T07:39:19+02:00

clawbot commented

2026-08-20 07:39:19 +02:00

next at aba02bc fails make test. Not caused by any open PR — two changes that each passed on their own base collided on next.

--- FAIL: TestGormScanIsNeverCalledOutsideTests (0.20s)
    scan_guard_test.go:205:
        Error: Should be empty, but was
               [internal/delivery/queue_depth.go:109:3 internal/delivery/queue_depth.go:161:3]
FAIL	sneak.berlin/go/webhooker/internal/gormlog	0.924s

Reproduced on a pristine detached checkout of origin/next with no branch merged in, and again in a cache-defeated docker build --no-cache-filter=builder. Every other package passes; this is the only failing one.

internal/gormlog/scan_guard_test.go forbids (*gorm.DB).Scan in non-test code, because Scan swaps GORM's own trace recorder in for the logging adapter and that recorder does not implement gorm.ParamsFilter, so the statement is logged with its bound values interpolated. Both call sites in internal/delivery/queue_depth.go are real instances:

:109 — e.database.DB().Model(&database.Target{}).Select("id", "type").Scan(&rows)
:161 — the queued-delivery count, whose Where("status IN ?", ...) binds values

The guard's own message names the fix: Find, Pluck, or Raw(...).Row().Scan. :109 selects two columns into a struct slice, so Find fits; :161 aggregates, so Raw(...).Rows() or a Pluck is the shape.

The bound values here are delivery statuses rather than secrets, so the disclosure is minor; the breakage is that next does not build, which blocks the milestone.

Found while running the gate for #223, which does not touch either file.

`next` at `aba02bc` fails `make test`. Not caused by any open PR — two changes that each passed on their own base collided on `next`. ``` --- FAIL: TestGormScanIsNeverCalledOutsideTests (0.20s) scan_guard_test.go:205: Error: Should be empty, but was [internal/delivery/queue_depth.go:109:3 internal/delivery/queue_depth.go:161:3] FAIL sneak.berlin/go/webhooker/internal/gormlog 0.924s ``` Reproduced on a pristine detached checkout of `origin/next` with no branch merged in, and again in a cache-defeated `docker build --no-cache-filter=builder`. Every other package passes; this is the only failing one. `internal/gormlog/scan_guard_test.go` forbids `(*gorm.DB).Scan` in non-test code, because `Scan` swaps GORM's own trace recorder in for the logging adapter and that recorder does not implement `gorm.ParamsFilter`, so the statement is logged with its bound values interpolated. Both call sites in `internal/delivery/queue_depth.go` are real instances: - `:109` — `e.database.DB().Model(&database.Target{}).Select("id", "type").Scan(&rows)` - `:161` — the queued-delivery count, whose `Where("status IN ?", ...)` binds values The guard's own message names the fix: `Find`, `Pluck`, or `Raw(...).Row().Scan`. `:109` selects two columns into a struct slice, so `Find` fits; `:161` aggregates, so `Raw(...).Rows()` or a `Pluck` is the shape. The bound values here are delivery statuses rather than secrets, so the disclosure is minor; the breakage is that `next` does not build, which blocks the milestone. Found while running the gate for https://git.eeqj.de/sneak/webhooker/pulls/223, which does not touch either file.

clawbot referenced this issue

2026-08-20 07:39:55 +02:00

Stop target credentials leaking into event databases (closes #206) #223

clawbot referenced this issue

2026-08-20 07:40:25 +02:00

Stop target credentials leaking into event databases (closes #206) #223

clawbot commented

2026-08-20 07:41:24 +02:00

Duplicate of #234, filed a few minutes earlier for the same failure. Two workers hit the red next independently and both filed rather than assuming it was known — the right instinct, and cheap compared to the alternative.

The fix is dispatched against #234. Closing this one; no work is lost.

Duplicate of https://git.eeqj.de/sneak/webhooker/issues/234, filed a few minutes earlier for the same failure. Two workers hit the red `next` independently and both filed rather than assuming it was known — the right instinct, and cheap compared to the alternative. The fix is dispatched against https://git.eeqj.de/sneak/webhooker/issues/234. Closing this one; no work is lost.

clawbot closed this issue

2026-08-20 07:41:25 +02:00

clawbot referenced this issue

2026-08-20 07:48:48 +02:00

Stop target credentials leaking into event databases (closes #206) #223

Sign in to join this conversation.