Delete duplicate scanning

[eric-pSAP]

Await setting the scan status to 'scanning' to avoid race condition.

[hyperspace-insights]

The change is clear and correct. The async inner callback in cds.tx(...) already returns a Promise, but without await the outer rescan function would not wait for the transaction to commit before proceeding to spawn the scan event and throw. Adding await ensures the status is persisted before the next steps execute — exactly the fix described.

The implementation looks correct. No issues to flag.

The PR is a minimal, focused fix: adding await to cds.tx(...) ensures the "Scanning" status is committed to the database before the scan event is emitted and the 202 error is thrown, correctly resolving the race condition described in the PR.

PR Bot Information

Version: 1.20.37

• LLM: anthropic--claude-4.6-sonnet
• Correlation ID: c9b54f16-4421-411e-8865-1081a48c2bb6
• Event Trigger: pull_request.opened
• File Content Strategy: Full file content

[eric-pSAP]

Scanning status is only set in 2 places. Since scanAttachmentsFile always sets the status before it can become clean, that means cds.tx is resolving late under load and thus setting the status to "Scanning" after the scan.

[hyperspace-insights]

Summary

The following content is AI-generated and provides a summary of the pull request:

---

Fix Race Condition in Duplicate Scan Prevention

Bug Fix

🐛 Removed a redundant function call that was setting the scan status to "Scanning" prior to emitting the scan event. This extra cds.tx call was causing a race condition when triggering re-scans for attachments with expired or missing scan dates.

Changes

• lib/generic-handlers.js: Removed the standalone cds.tx block that pre-emptively set the attachment status to "Scanning" before emitting the ScanAttachmentsFile event. This eliminates the race condition introduced by having two concurrent transactions attempting to update the scan status.
• CHANGELOG.md: Added version 3.13.0 entry documenting the fix for the extra status-setting function that caused race conditions.

---

• 🔄 Regenerate and Update Summary
• ✏️ Insert as PR Description (deletes this comment)
• 🗑️ Delete comment

PR Bot Information

Version: 1.20.43

• LLM: anthropic--claude-4.6-sonnet
• Output Template: Default Template
• Summary Prompt: Default Prompt
• Correlation ID: f51bd84a-d48d-4fb4-9e11-42b0c717dde5
• File Content Strategy: Full file content
• Event Trigger: pull_request.ready_for_review

[hyperspace-insights]

The analysis is complete. The scanAttachmentsFile handler in malwareScanner.js calls await this.updateStatus(_target, keys, "Scanning") at line 72 as its first substantive action inside a committed transaction. The deleted cds.tx(...) call in generic-handlers.js was fire-and-forget (no await), meaning it ran asynchronously in a separate transaction that could resolve after the scan had already completed — which is exactly the race condition described in the PR comment.

Now let me check the CHANGELOG entry wording against the actual change:

The CHANGELOG says "Fixed: Remove extra function setting status to scanning to avoid race conditions." The PR description says "Await setting the scan status to 'scanning' to avoid race condition." The actual fix removes the duplicate, not awaits anything — the CHANGELOG wording is accurate, but the PR description is misleading. That's just a description issue, not a code issue.

The code change itself looks correct. No substantive code issues to flag.

The PR is a clean, well-reasoned fix. The unawaited cds.tx(...) call was correctly identified as the source of the race condition, and removing it is the right solution since scanAttachmentsFile already sets status to "Scanning" as its first committed step. No code defects were found.

PR Bot Information

Version: 1.20.43

• Correlation ID: f51bd84a-d48d-4fb4-9e11-42b0c717dde5
• File Content Strategy: Full file content
• Event Trigger: pull_request.ready_for_review
• LLM: anthropic--claude-4.6-sonnet