Problem
The deployment CLI classifies non-immutable CDN files (create/replace/unchanged) by fetching their current content from the public Bunny pull-zone (scripts.simpleanalyticscdn.com), and it uses that classification both for the preview shown to the operator and to decide which files to skip during a real deployment. Non-immutable CDN uploads are not re-checked against the authoritative storage API before writing (only immutable SRI targets are). Because the public pull-zone is a cache downstream of storage, it can be stale relative to storage. In that window the tool can mark a file "unchanged" and skip a needed upload, or mark an already-current file "replace" and upload it again. It can also, in rare concurrent-deploy situations, miss that storage holds different content than what the public edge is serving. The impact is limited under normal single-operator use, but the skip decision for production tracking scripts depends on a cache rather than the source of truth.
Suggested changes
- Read current CDN content from the Bunny storage API (storage.bunnycdn.com with the access key) rather than the public pull-zone when computing preview status and skip decisions, at least when credentials are available (e.g. real deployments).
- Apply the same authoritative re-check before upload that immutable files receive to non-immutable CDN files, so a stale-cache classification cannot cause a needed upload to be skipped.
- If public-endpoint reads are retained for credential-free dry runs, surface in the preview that the comparison is against the cached public copy, not storage.
- Add a regression test covering the case where storage and the public pull-zone disagree to lock in the intended source-of-truth behavior.
Problem
The deployment CLI classifies non-immutable CDN files (create/replace/unchanged) by fetching their current content from the public Bunny pull-zone (scripts.simpleanalyticscdn.com), and it uses that classification both for the preview shown to the operator and to decide which files to skip during a real deployment. Non-immutable CDN uploads are not re-checked against the authoritative storage API before writing (only immutable SRI targets are). Because the public pull-zone is a cache downstream of storage, it can be stale relative to storage. In that window the tool can mark a file "unchanged" and skip a needed upload, or mark an already-current file "replace" and upload it again. It can also, in rare concurrent-deploy situations, miss that storage holds different content than what the public edge is serving. The impact is limited under normal single-operator use, but the skip decision for production tracking scripts depends on a cache rather than the source of truth.
Suggested changes