Skip to content

feat(bulk-assets): retry publishing assets whose scan was pending - #363

Open
naman-contentstack wants to merge 2 commits into
developmentfrom
feat/DX-9663
Open

feat(bulk-assets): retry publishing assets whose scan was pending#363
naman-contentstack wants to merge 2 commits into
developmentfrom
feat/DX-9663

Conversation

@naman-contentstack

Copy link
Copy Markdown
Contributor

Problem

When cm:stacks:bulk-assets publishes, every asset carries a malware scan status
of clean, pending or quarantined. pending only means the scan has not
finished yet, but it was treated the same as quarantined — skipped with a
console warning and then forgotten. Nothing recorded which assets were skipped,
so once a scan finished there was no way to publish them short of re-running the
whole publish and hoping the timing worked out. For a large publish that is a
handful of assets silently left unpublished with no path forward.

Fix

  • Both publish paths (the normal fetch flow and the --data-dir flow) now record
    pending-skipped assets to pending-scan.json in the bulk operation folder,
    alongside the existing success/failed logs. Each entry carries uid, locale,
    version, environments, apiKey and branch — enough to rebuild the publish call
    without re-fetching the asset.
  • New --retry-pending <folder> flag re-checks scan status via the existing
    AssetService.fetchScanStatusByUIDs, then publishes only the assets that came
    back clean, through the same executeBulkOperation path every other flow uses.
    Config is read back from the log, so no --operation/--environments/--locales
    needed (CLI flags still override).
  • The log self-prunes: a retry rewrites it with only the still-pending entries,
    dropping what it published and anything that turned quarantined. Quarantined
    assets are never retried — that skip is intentional and permanent.
  • pending-scan.json is deliberately excluded from clearLogs(). A scan can
    outlast the gap between two unrelated runs, and wiping it would lose the only
    record of what needs retrying.
  • Writes are batched to one per run, not one per asset — the --data-dir path
    collects entries through its streaming loop and writes once at the end, so the
    one-chunk-at-a-time memory behaviour is preserved.
  • --retry-pending is rejected for unpublish, delete and move, since scan
    status only gates publish.

Assets still being scanned for malware were skipped on every publish run
with only a console warning, leaving no way to publish them once the scan
finished. Record those skips to pending-scan.json in the bulk operation
folder, and add --retry-pending to re-check their status and publish the
ones that came back clean.

The log is self-pruning: a retry drops the entries it published along with
any that turned quarantined, keeping only those still scanning. It is also
excluded from clearLogs(), since a scan can outlast the gap between two
unrelated runs.

Quarantined assets are never retried, and the flag is rejected for
unpublish, delete and move — scan status only gates publish.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@naman-contentstack
naman-contentstack requested a review from a team as a code owner August 27, 2026 09:36
@naman-contentstack naman-contentstack self-assigned this Aug 27, 2026
@github-actions

Copy link
Copy Markdown

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type Count (with fixes) Without fixes Threshold Result
🔴 Critical Severity 0 0 10 ✅ Passed
🟠 High Severity 0 246 25 ✅ Passed
🟡 Medium Severity 0 0 500 ✅ Passed
🔵 Low Severity 0 0 1000 ✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity Breaches (with fixes) Breaches (no fixes) SLA Threshold (with/no fixes) Status
🔴 Critical 0 0 15 / 30 days ✅ Passed
🟠 High 0 0 30 / 120 days ✅ Passed
🟡 Medium 0 0 90 / 365 days ✅ Passed
🔵 Low 0 0 180 / 365 days ✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

  • Critical without fixes: 0
  • High without fixes: 246
  • Medium without fixes: 0
  • Low without fixes: 0

✅ BUILD PASSED - All security checks passed

@snyk-io

snyk-io Bot commented Aug 27, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@github-actions

Copy link
Copy Markdown

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type Count (with fixes) Without fixes Threshold Result
🔴 Critical Severity 0 0 10 ✅ Passed
🟠 High Severity 0 2 25 ✅ Passed
🟡 Medium Severity 0 0 500 ✅ Passed
🔵 Low Severity 0 0 1000 ✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity Breaches (with fixes) Breaches (no fixes) SLA Threshold (with/no fixes) Status
🔴 Critical 0 0 15 / 30 days ✅ Passed
🟠 High 0 0 30 / 120 days ✅ Passed
🟡 Medium 0 0 90 / 365 days ✅ Passed
🔵 Low 0 0 180 / 365 days ✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

  • Critical without fixes: 0
  • High without fixes: 2
  • Medium without fixes: 0
  • Low without fixes: 0

✅ BUILD PASSED - All security checks passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant