CMG-1108 | WordPress delta assets not showing on Map Entry Assets screen - #1143
Conversation
…ing key extractAssets used the bare wp:post_id as otherCmsAssetUid, but the CLI import stages assets under assets_<post_id>. The mismatch meant WordPress asset uids never resolved, so migrated assets vanished from the Map Entry Assets screen on delta iterations.
Assets were hidden on iteration 2+ unless already migrated, unlike entries which always show new and updated items together. Removes that filter so both screens behave consistently across all CMS connectors.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
🔒 Security Scan Results
⏱️ SLA Breach Summary
🟠 High Severity - SLA Breached Issues (with fixes)Showing 2 issue(s) that have exceeded the 30-day SLA threshold:
ℹ️ 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:
❌ BUILD FAILED - Security checks failed Please review and fix the security vulnerabilities before merging. |
chetan-contentstack
changed the title
There was a problem hiding this comment.
Pull request overview
Fixes delta-migration asset visibility and UID resolution.
Changes:
- Aligns WordPress asset mapping IDs with CLI UID keys.
- Displays new and existing assets on later iterations.
- Adds coverage for iteration 2+ asset visibility.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
upload-api/migration-wordpress/libs/extractAssets.ts |
Prefixes WordPress asset UIDs. |
api/src/services/contentMapper.service.ts |
Removes delta asset filtering. |
api/tests/unit/services/contentMapper.service.test.ts |
Tests new-asset visibility. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
cs_failed.json write on a failed WordPress attachment download used the bare wp:post_id instead of customId (assets_<wp:post_id>), which is the only key getAssetMapping looks up via otherCmsAssetUid. Failed WordPress attachments were silently reported as "ok" instead of "failed".
🔒 Security Scan Results
⏱️ SLA Breach Summary
🟠 High Severity - SLA Breached Issues (with fixes)Showing 2 issue(s) that have exceeded the 30-day SLA threshold:
ℹ️ 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:
❌ BUILD FAILED - Security checks failed Please review and fix the security vulnerabilities before merging. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Suppressed comments (3)
upload-api/migration-wordpress/libs/extractAssets.ts:84
- Aligning this UID with
index.jsonalso makesputTestDatafind prior metadata, but every WordPress asset is then guaranteed to be classified as changed: this extractor reports the source filename andfile_size: '', whilesaveAssetstagesassets_<id><ext>with a populated size, andcontentMapper.service.ts:284-287compares those fields literally. Consequently, an unchanged attachment is preselected for an in-place binary update on every delta run. Compare stable source metadata (for example the URL), omit unavailable fields from change detection, or emit metadata in the same canonical form as the staged asset.
otherCmsAssetUid: `assets_${id}`,
api/src/services/wordpress.service.ts:1927
- Changing the key does not make WordPress failures visible to
getAssetMapping: this record is persisted throughfailedJSONFilePath, which is initialized under<data>/<stack>/logs/assets, whilecontentMapper.service.ts:2524-2529only reads<data>/<stack>/assets/<ASSETS_FAILED_FILE>. The row will therefore still be reported asok. Write/read a common operational failure file (while preserving any separate log copy if needed).
failedJSON[customId] = {
failedUid: customId,
api/src/services/wordpress.service.ts:1927
- Once this WordPress failure is surfaced as
status: 'failed', the shared Assets table renders a Retry button for it (assetMapper.tsx:346-365), butretryAssetDownloadrejects every CMS except Contentful (contentMapper.service.ts:2419-2423). Either implement WordPress retry handling or suppress/disable the action for connectors that cannot retry; otherwise the newly exposed recovery control always fails.
failedUid: customId,
🔒 Security Scan Results
⏱️ SLA Breach Summary
ℹ️ 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:
Consider reviewing these vulnerabilities when fixes become available. |
cs_failed.json write on a failed WordPress attachment download used the bare wp:post_id instead of customId (assets_<wp:post_id>), which is the only key getAssetMapping looks up via otherCmsAssetUid. Failed WordPress attachments were silently reported as "ok" instead of "failed".
🔗 Jira Tickets
📋 PR Type
📝 Description
What changed?
extractAssets.ts— WordPress asset extraction tagged each asset'sotherCmsAssetUidwith the barewp:post_id(e.g."301"), but the CLI import stages that same asset underassets_301and writes its resolved Contentstack uid back intouid-mapping.jsonunder that prefixed key. The mismatch meant a WordPress asset's uid could never resolve, so on delta iterations (2+) — where the Map Entry Assets screen only showed rows with a resolved uid — every previously-migrated WordPress asset silently disappeared from the screen, even though it had migrated successfully. Fixed by prefixingotherCmsAssetUidwithassets_to match the CLI's key.contentMapper.service.ts— separately, the Map Entry Assets screen filtered out brand-new (never-before-migrated) assets on iteration 2+ entirely, while the equivalent Map Entry (entries) screen always shows new and updated items together. Removed that filter so assets behave the same as entries. This logic is shared and CMS-agnostic, so it applies uniformly to WordPress, Drupal, Contentful, AEM, and Sitecore.Why?
Reported in CMG-1108: assets added in a WordPress delta migration's second iteration were confirmed present in the destination stack but never appeared in the review UI, with no way to tell they'd migrated. Root-caused via a real test project's on-disk
uid-mapper.jsonand CLI staging output (the initial static-analysis theory needed live confirmation — see PR discussion). While fixing it, confirmed the asset screen's "hide brand-new items" behavior was inconsistent with the entries screen and had no equivalent justification, so aligned the two.🧩 Affected Areas
api— Node.js backendui— React frontendupload-api— Upload API serverdocker/docker-compose🧪 How to Test
wp:post_type=attachment) that gets a real Contentstack uid, then re-export the same asset in an iteration 2 WXR file and run the delta migration. Check Map Entry Assets on iteration 2 — the asset is missing, despite being visible in the destination stack's Assets list.cd api && npx vitest run tests/unit— 743/743 passing.cd upload-api && npx vitest run— 302/302 passing.Expected result: WordPress assets correctly resolve their prior Contentstack uid on delta iterations, and the Map Entry Assets screen shows every asset (new and previously-migrated) consistently with how entries already display.
📸 Screenshots / Recordings
🔗 Related PRs / Dependencies
dev.✅ Author Checklist
bugfix/cmg-1108-1109-wordpress-delta.env/example.envupdated — N/Anpx vitest run tests/unitinapi/— 743/743,npx vitest runinupload-api/— 302/302)contentMapper.service.test.tsREADME.md/ docs updated — N/A👀 Reviewer Notes
uid-mapper.jsonand CLI-staged asset files on disk — reading the extraction/write code alone made it look plausible but not provably broken, since the two functions that produce/consume the uid live in different files (extractAssets.tsvswordpress.service.ts).