lisa/control-suggestion-state-api#425
Conversation
gusfcarvalho
left a comment
There was a problem hiding this comment.
Findings inline (1 Medium, 2 Low — non-blocking). Solid change overall: cross-cell aggregation is order-independent and well-tested, latest-per-control supersession is correct, and writes are transaction-gated. Headline: outcome is derived from newly-inserted rows rather than from whether the LLM matched the control, so capped/excluded/rerun-deduped controls record no_match despite a real match — worth confirming the UI cross-references pending suggestions. Two redundant indexes noted.
gusfcarvalho
left a comment
There was a problem hiding this comment.
All three findings from the prior round are addressed in fbe957b and verified:
- Medium (outcome derivation) —
recordControlResultsTxnow decidesmatchedfrommatchedControlKeySet(validation.Mappings)(LLM-matched controls) rather than insert success, whileSuggestionCountstays on newly-inserted counts. A control whose mappings were capped / excluded / rerun-deduped now correctly recordsoutcome: matched, suggestion_count: 0, with a new test covering the run-cap case. No-match upserts stillDO NOTHING, so a later empty cell cannot downgrade an earlier match. - Low — redundant
indexdropped from bothRunIDandOutcomegorm tags; the composite unique index(run_id, control_catalog_id, control_id)is intact for the upsert conflict target.
Verified locally: go build ./... clean, worker + suggestions packages pass. CI green. LGTM.
|
PR approved. Marking as ready for e2e. |
automated implementation by lisa.