chore(wfengine): review-minor sweep — retry comment, doc, test assertions (bookshelf-vguw.6, bookshelf-vguw.18) #611
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "bd-bookshelf-vguw.6"
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
Non-blocking review minors from two merged PRs (#327 and #339), combined into one tight sweep:
vguw.6 — #327 minors:
cover_workflow.go: Replace misleading "mirrors old pool policy" comment with the actual go-workflows backoff sequence (30s/60s/120s/240s capped at 5m) and note the minor difference from the old task-pool policy ([0s, 30s, 60s, 120s, 300s]). Chose to fix the comment rather than adjust intervals — the 30s-vs-immediate difference at attempt 1 is not worth the complexity.cover_handler.go: Addlogger.Warnfor the discardedjson.Encodeerror afterWriteHeader(previously silently swallowed with_ =). Out-of-scope items (book_id logged before existence, per-bookID idempotency) are tracked in vpu8.cover_handler_test.go: Split two-ExpectIt("generic message" + "no leak") into twoIts; addCoverHandler encode-errorDescribe with anerrorWriterstub to cover the new Warn path.engine_integration_test.go: Split four-ExpectIt(POST cover 202 + instance_id) into a sub-Context with nestedJustBeforeEachand three single-ExpectIts.vguw.18 — #339 minors:
engine.go: Fix package-doc commentEngine.Start/Stop→Engine.StartWorker/Stopto match the actual method name.engine_lifecycle_test.go: AddWorkerStarted()==trueassertion to theStartWorkersuccessContext; addWorkerStarted()==falseassertion to theStartWorkererrorContext.Test plan
make lint(wfengine package): 0 issuesgo test ./internal/wfengine/...: passmake coverage: 100% oninternal/wfengine, full gate passesCloses bead bookshelf-vguw.6 and bookshelf-vguw.18 on merge.
SECURITY REVIEW — PR #611 (bd-bookshelf-vguw.6)
This is the automated security review. Diff reviewed:
origin/main...origin/bd-bookshelf-vguw.6.Changes in scope: logger.Warn on discarded json.Encode error (
cover_handler.go), doc-comment rename (engine.go), retry-schedule comment expansion (cover_workflow.go), and test-assertion additions (cover_handler_test.go,engine_integration_test.go,engine_lifecycle_test.go).New logger.Warn — sensitive-data audit
File:
internal/wfengine/cover_handler.go(new lines added in the diff):Fields logged:
book_id— anint64parsed from the URL path value/admin/workflows/_poc/cover/{bookID}. This is a non-sensitive internal integer identifier already visible to the caller in the URL. No PII, no token, no secret.err— the error fromjson.Encoder.Write, which is a network/transport error (e.g. "write failed", "broken pipe"). These are stdlib/OS-level error strings that carry no user data, credentials, or internal path information beyond the transport error itself."wfengine: cover handler: encode response") — no interpolation.Conclusion: No sensitive data logged. Logging follows the structured key-value pattern mandated by
logging-standard.md(not concatenated into a string). No PII, tokens, or secrets present.Auth / Authorization surface
No changes to auth checks, middleware, or session handling. The endpoint is admin-only (
/admin/workflows/_poc/cover/{bookID}); the diff does not alter the route or any access control on it.Input handling
No changes to the
strconv.ParseIntvalidation or thebookID <= 0guard. The new code runs after the 202 has already been written; there is no new user-controlled value in the log path.Resource bounds / unbounded queries / injection
No new SQL queries, no new fan-out, no new external calls introduced. The diff is purely: error capture → structured log. No injection surface added.
Other paths
engine.go: single comment-word rename (Start→StartWorker) in a package doc. No behavioral change.cover_workflow.go: doc-comment expansion explaining the retry schedule arithmetic. No behavioral change; theActivityOptionsvalues themselves are unchanged.REVIEW VERDICT: 0 blocker, 0 major, 0 minor
This is a clean nit sweep. The security surface is minimal: the sole new production line logs two non-sensitive structured fields after a 202 has already been sent. No auth, injection, secret-leakage, or resource-bound concerns.
CODE REVIEW: NOT APPROVED
Phase 0: DEMO Verification
No DEMO block is applicable for this review-minor sweep (no new user-facing behaviour). Proceeding directly to code quality.
Phase 1: Spec Compliance
All five stated changes are present in the diff:
cover_workflow.go: retry comment updatedcover_handler.go: discardedjson.Encodeerror now logsWarncover_handler_test.go: two-ExpectItsplit + newerrorWriterDescribeengine_integration_test.go: four-ExpectItsplitengine.go: package-doc corrected toEngine.StartWorkerengine_lifecycle_test.go:WorkerStarted()assertions addedPhase 2: Code Quality
[BLOCKER] internal/wfengine/cover_workflow.go:15-22 — corrected retry comment shows the wrong delay sequence
The comment was introduced as a "correction" but it is numerically wrong. The go-workflows retry loop in
workflow/retries.go:87computes:…where
attemptis post-incremented (line 71:attempt++) before the backoff calculation. So on the first retryattempt == 1, not 0. WithFirstRetryInterval=30sandBackoffCoefficient=2, the actual sequence is:The comment also says "capped at MaxRetryInterval = 5m on attempt 4+". The cap does first fire on the 4th retry (480s > 300s), so the capping-starts note is coincidentally correct, but the values shown are all wrong by one power of 2.
A wrong "correction" is worse than the original vague comment because it looks authoritative while being incorrect. Either revert to the old non-numeric comment, or fix the sequence to use the 1-indexed
attemptvalues above.[MINOR] internal/wfengine/engine_integration_test.go:263-283 —
JustBeforeEachsilently discards the JSON decode errorThe split
Itblocks share state set inJustBeforeEach:If encoding fails or the body is empty,
body.InstanceIDstays zero and theIt("returns a non-empty instance_id")test fails with an unhelpful message likeExpected '' not to be empty. PreferExpect(json.NewDecoder(resp.Body).Decode(&body)).To(Succeed())so a bad body gives a direct failure at the decode step rather than a misleading assertion on the empty field.REVIEW VERDICT: 1 blocker, 0 major, 1 minor
672fed37e44a5aa8cd79