Repository navigation
fix(conformance): correct P023's fix guidance (1 repo) - #4711
Conversation
Opened by the conformance remediation lane.
The corrected P023 guidance tells an async producer feeding a sync sink to offload each sink call (`await run_in_thread(fh.write, chunk)`). Pin that the detector accepts this shape, alongside the on-loop write it still catches, so the guidance can't drift into recommending a fix that stays flagged. Claude-Session: https://claude.ai/code/session_01AbKqGZp7MEAd51EaXtM6Gi
…-hop offload The streaming exception prescribed per-chunk `run_in_thread(fh.write, chunk)` while leaving `with open(...)` on the loop, which contradicts the rule's own "offloading the send alone while the open stays on the loop moves half the cost". Tell the sink's open and close to be offloaded the same way, regenerate the rule docs, and pin that fully offloaded shape as silent. Claude-Session: https://claude.ai/code/session_01AbKqGZp7MEAd51EaXtM6Gi
|
/lens |
lens summary · updated after round 2 (re-review · only commits since e65c06f)✅ Ready to merge — every finding is resolved Open findings: 🔴 0 critical · 🟠 0 high · 🟡 0 medium · ⚪ 0 low (nit) lens reads this PR as — P023 correctly detects blocking synchronous sink calls in async code, but its whole-block offloading guidance did not fit an async producer streaming into a synchronous sink: following it could force moving the producer into sync code or buffering the response, changing streaming behavior. How: The PR preserves whole-block offloading for wholly synchronous work while documenting a streaming exception: keep the async producer awaited and sequentially offload each sink operation, including open and close. It updates the prescription sources and rule description, with focused tests that check the on-loop write is reported and the offloaded streaming form is not; detection itself is unchanged. Approach check — sound. ✔️ Resolved (1)
🕘 Round history (2)
round 2 · $0.037 of $1.00 · 35 model calls · 0 failed requests · 85% prompt cache hits · gpt-6-luna |
File open/write/close take no timeout, so per-chunk run_in_thread offload cannot bound a sink that hangs, and run_in_thread's own progress hold is unbounded. Prescribe a bounded holding_progress around the open-through-close span so a wedged sink fails the task at a chosen bound, and say that the stuck thread itself is not recovered. Claude-Session: https://claude.ai/code/session_01AbKqGZp7MEAd51EaXtM6Gi
|
/lens |
|
✅ lens · round 2 · re-review · only commits since e65c06f — ready to merge — every finding resolved · $0.04 Open findings: 🔴 0 critical · 🟠 0 high · 🟡 0 medium · ⚪ 0 low (nit) Approach check — ✅ sound
$0.037 of $1.00 · 35 model calls · 0 failed requests |
atlan-ci
left a comment
There was a problem hiding this comment.
lens: ready to merge — every finding at every level is resolved (round 2).
P023: fix guidance corrected in the rule
Updated P023's full description and prescription to keep whole-block offloading for wholly synchronous work while explicitly allowing streaming async producers with sequential per-chunk offloading of synchronous sink calls (
await run_in_thread(handle.write, chunk)). The clarification preserves streaming and avoids moving the async producer into sync code or buffering the whole response. Followed the Metabase callable-offload pattern, with the Tableau streaming case as the documented exception. The detector was unchanged and still reports 86 Tableau findings, 8 Metabase findings, and 0 for MySQL/OpenAPI. Ruff passed; the focused documentation/prescription tests passed (568 passed, 1 xfailed). The import check is unavailable in this rule-fix task.atlanhq/atlan-tableau-app→ 86,atlanhq/atlan-mysql-app→ 0,atlanhq/atlan-metabase-app→ 8,atlanhq/atlan-openapi-app→ 0Reviewer evidence
Opened by the conformance remediation lane (agent-sdk). Never merged automatically.
Tracking: FND-4530