Skip to content

fix(import): clarify global field reference-field warning message - #351

Open
harshitha-cstk wants to merge 1 commit into
developmentfrom
fix/dx-10153-global-field-reference-warning
Open

fix(import): clarify global field reference-field warning message#351
harshitha-cstk wants to merge 1 commit into
developmentfrom
fix/dx-10153-global-field-reference-warning

Conversation

@harshitha-cstk

Copy link
Copy Markdown
Contributor

What

Rewords the warning logged during cm:stacks:import / cm:stacks:clone when a global field references a content type that hasn't been imported yet.

Before:

Content type landing_page does not exist. Removing the field from schema...

After:

Content type 'landing_page' is not imported yet; its reference will be restored once it is imported.

Why (DX-10153)

DX-10153 reported that global fields permanently lose content-type reference fields during import/clone, with no restoration pass.

Investigation showed this is not a bug — the restoration already exists:

  • Global fields import before content types, so any global field with a reference field is deferred (added to a pending list), not permanently stripped.
  • After content types are created, the content-types module re-updates those global fields from the original schema (handlePendingGlobalFieldsupdatePendingGFs).

Verified end-to-end: after import, all affected reference fields are present in the target stack and match the source. cm:stacks:clone runs the same import path, so it behaves identically.

The actual problem was the misleading warning — "Removing the field from schema..." reads as permanent data loss even though the reference is restored moments later in the same run. This PR fixes only that wording.

Scope

  • One-line message change in packages/contentstack-import/src/utils/content-type-helper.ts.
  • No behavior change.

🤖 Generated with Claude Code

Reword the warning logged when a referenced content type is not yet
imported so it no longer implies permanent data loss. The reference is
deferred and restored later in the same run, so the previous
"Removing the field from schema..." wording was misleading.

DX-10153

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@harshitha-cstk
harshitha-cstk requested a review from a team as a code owner August 18, 2026 06:36
@snyk-io

snyk-io Bot commented Aug 18, 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 0 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

✅ 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.

2 participants