fix(workspace-server): check rows.Err() after iteration in MemoryHandler.List #1748
Reference in New Issue
Block a user
Delete Branch "fix/memory-list-rows-err"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The
MemoryHandler.Listhandler iterated overrows.Next()but never checkedrows.Err()after the loop. If the database connection fails during iteration (e.g., storage engine fault, network partition), the error is silently swallowed and partial results are returned with HTTP 200 OK.Changes
rows.Err()guard after the scan loop that returns 500 when iteration encounters an error.TestMemoryList_RowsErr_Returns500using sqlmockRowErrorto inject a mid-iteration fault.Safety
checkpoints.go,workspace_crud.go,channels.go, etc.Test plan
Platform (Go).Tracked: rows.Err() audit gap (follow-up to internal#348 / PR #1743).
LGTM. Adds rows.Err() guard after rows.Next() loop — prevents silent partial-result return on DB connection fault. sqlmock test covers the error path. Matches the rows.Err() pattern used in checkpoints and workspace_crud. Non-author 2nd-approve per CTO carve-out.
5-axis review on
600f88b:Correctness: APPROVED. MemoryHandler.List now checks rows.Err() after iteration and returns a 500 instead of silently returning partial results, matching the requested fix.
Robustness: The new sqlmock RowError regression test covers the iteration-error path and verifies the handler does not report success.
Security: No auth, secret, or input-validation surface changed.
Performance: Constant-time post-iteration check only; no material overhead.
Readability: The error handling is localized and consistent with the existing DB error response style.