[contentstackMridul]

Live Preview SDK v4.5.3: develop_v4 to stage_v4

Summary

Promotes develop_v4 into stage_v4 with the v4.5.3 release content: a fix for an unhandled promise rejection in the Visual Builder discussion-highlights messaging, the v4.5.2 release commits synced back from main (#658), and the v4.5.3 version bump. After this merges, stage_v4 is level with develop_v4 and ready for the final stage_v4 to main release PR.

What's changed

Fixes

• Discussion-highlight events no longer raise an unhandled promise rejection when the Visual Builder side has no listener mounted for them (fix(visual-builder): handle rejection when discussion highlights has no listener #652). The new ignoreMissingListener helper in src/visualBuilder/utils/postMessageErrors.ts swallows the library's missing-listener rejection and logs a console warning for any other send failure. Both send sites use it: useVariantsPostMessageEvent and useRecalculateVariantDataCSLPValues.

Tests

• New specs cover the error helper and both send sites, including the split between an ignored missing listener and a warned real failure.

Synced from main (v4.5.2 release, via #658)

• Release workflow fixes from fix(release): restore build before publish and the alpha dist-tag #650: the package builds on prepack so dist ships in the published tarball, prereleases publish under the alpha dist-tag, and the retired alpha-publish workflow file is removed.
• CI: vitest-coverage-report-action pinned to a commit sha.

Chores

• Version bump to 4.5.3; CHANGELOG regenerated via auto-changelog with a v4.5.3 section for the pending fix.
• README CDN snippet pinned to @contentstack/live-preview-utils@4.5.3.

Release path

• release: v4.5.3 (sync main into develop_v4) #658 merged into develop_v4
• Merge this PR (develop_v4 to stage_v4)
• Open and merge the stage_v4 to main release PR
• Create GitHub Release v4.5.3 from main (tag created via the Release UI), which triggers the npm-publish workflow
• Verify @contentstack/live-preview-utils@4.5.3 on npm and that https://esm.sh/@contentstack/live-preview-utils@4.5.3 resolves

---

🤖 Generated with Claude Code

[snyk-io]

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

🔒 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

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved issues were identified.

Review effort: Lite
Findings: None

What changed in this PR

Develop v4 adds safe handling for unavailable visual-builder postMessage listeners.

Changes:

• Adds reusable missing-listener rejection handling.
• Applies it to variant and mutation-triggered highlight requests.
• Adds unit and integration test coverage.

File	Description
src/​visualBuilder/​utils/​postMessageErrors.ts	Defines rejection filtering and warning behavior.
src/​visualBuilder/​utils/​__test__/​postMessageErrors.test.ts	Tests error handling behavior.
src/​visualBuilder/​eventManager/​useVariantsPostMessageEvent.ts	Handles rejected highlight requests.
src/​visualBuilder/​eventManager/​useRecalculateVariantDataCSLPValues.ts	Handles rejected observer-triggered requests.
src/​visualBuilder/​eventManager/​__test__/​useVariantsPostMessageEvent.spec.ts	Tests variant request rejection handling.
src/​visualBuilder/​eventManager/​__test__/​useRecalculateVariantDataCSLPValues.spec.ts	Tests observer request rejection handling.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	68.26%	2564 / 3756
🔵	Statements	67.12%	2605 / 3881
🔵	Functions	65.66%	461 / 702
🔵	Branches	62.58%	1547 / 2472

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/visualBuilder/eventManager/useRecalculateVariantDataCSLPValues.ts	44%	21.31%	50%	45.83%	41-43, 59, 66, 70, 73-92, 94, 104-148, 167-169, 192-194
src/visualBuilder/eventManager/useVariantsPostMessageEvent.ts	98.41%	93.1%	100%	98.38%	51
src/visualBuilder/utils/postMessageErrors.ts	100%	100%	100%	100%

Generated in workflow #926 for commit a220c07 by the Vitest Coverage Report Action

[hitesh-shetty-cstk]

Automated review

What this changes: Two fire-and-forget REQUEST_DISCUSSION_HIGHLIGHTS sends now attach a rejection handler. A new ignoreMissingListener helper returns silently when the receiver replies that no listener is registered for the event, and warns through PublicLogger for anything else. In useVariantFieldsPostMessageEvent the send also moves out of the SSR and CSR branches into a single call after them.

Business impact: none identified. The handler being restructured is the GET_VARIANT_ID path, so an error here would show up as variant switching on the canvas going wrong: classes not reapplied after a variant change, or discussion highlights not refreshing. I compared the hoisted send against the original and it is behaviour preserving, since both branches sent unconditionally before. The existing SSR and CSR assertions for that send are untouched and still pass through the same code path.

Security: nothing beyond what the scanners cover. No origin or payload validation changes. The value handed to PublicLogger.warn comes from the post message library itself, either a { code, message } object it constructs, an Error, or a fixed string, so the new log line does not put entry or user content into the console.

Flow

sequenceDiagram
    participant VB as Visual Builder (parent window)
    participant SDK as Live Preview SDK (iframe)
    VB->>SDK: GET_VARIANT_ID / VARIANT_PATCH
    alt CSR
        SDK->>SDK: updateVariantClasses() installs MutationObservers
        SDK->>SDK: debounced requestDiscussionHighlights()
    else SSR
        SDK->>SDK: addVariantFieldClass(variant)
    end
    SDK->>VB: send REQUEST_DISCUSSION_HIGHLIGHTS
    Note over SDK: changed here
    alt Discussions panel mounted
        VB-->>SDK: response, highlights recomputed
    else panel closed, no listener
        VB-->>SDK: reject { code: NO_REQUEST_LISTENER_FOUND }
        SDK->>SDK: ignoreMissingListener returns, no log
    else no ACK within 1s
        VB--xSDK: reject (uncoded string)
        SDK->>SDK: PublicLogger.warn
    end

Loading

Findings: 0 blocker, 0 should fix, 1 nit. The nit is inline, on the new observer spec.

Since the finding count is low, here is what I checked against the dependency rather than assumed, so the verdict is reviewable:

• ERROR_CODES.receiveEvent.noRequestListenerFound is exactly the string NO_REQUEST_LISTENER_FOUND in @contentstack/advanced-post-message@0.0.5, and the receiver replies with error: { code, message } when its request handler map has no entry for the type. The equality check in the helper matches the real wire value.
• send is declared as Promise<ReturnType>, so .catch type checks, and visualBuilderPostMessage?.send(...).catch(...) short circuits as one chain when the manager is undefined. No new failure path when the SDK runs outside an iframe.
• The no-ACK path rejects with a bare string after 1s and the closed-window path with an uncoded Error. Neither carries a code, which is what the helper's JSDoc claims and what the tests pin.
• On the builder side the listener is registered in an effect that unregisters when the Discussions panel unmounts, so the silent branch is the ordinary case and the warn branch needs the parent to stop acking altogether.

One thing I looked at and am leaving out of scope: the same unhandled rejection shape exists at the other fire-and-forget sends in this repo, SEND_VARIANT_AND_LOCALE in visualBuilder/index.ts, MOUSE_CLICK and FOCUS_FIELD in listeners/mouseClick.ts, and the two in utils/instanceHandlers.ts. Those are quiet today only because their listeners are registered once at builder level rather than with a panel, which is an assumption nothing enforces. A follow-up applying this helper there would be worth more than widening this PR.

Reviewer candidates:

• @karancs06 authored the two most recent commits on useRecalculateVariantDataCSLPValues.ts and 3 of the last 30 on useVariantsPostMessageEvent.ts.
• @csAyushDubey authored 5 of the last 30 commits on useVariantsPostMessageEvent.ts.

The heaviest author across these files is @hitesh-shetty-cstk, with 12 of the last 30 commits on useVariantsPostMessageEvent.ts and 6 of the last 13 on its spec. That is the account posting this automated review, so it is named here to consult rather than requested.

Not covered: I did not run the test suite, the type check, or the build, and I did not exercise the Discussions panel against a running builder. Dependencies are not installed in this environment, so the library behaviour above was read from the published package rather than observed. Whether the 200 ms debounce plus the direct send produces duplicate highlight recomputation in CSR is pre-existing and not something I measured.

Automated review by Claude Code. A human review is still required.

---

Generated by Claude Code

[Copilot]

Copilot review overview

🟡 Changes recommended

Correct the duplicate release entry, changelog typo, and outdated README package version reference.

Review effort: Lite
Findings: 3

Open (3)

• Duplicate v4.5.2 changelog entry with empty comparison · New
• Correct misspelled Assets heading · New
• Update README CDN references to version 4.5.2 · New

[kirtesh-cstk]

LGTM

[github-actions]

🔒 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

[github-actions]

🔒 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

[Copilot]

Copilot review overview

🟡 Changes recommended

The alpha publishing routing, release-version alignment, and changelog heading must be corrected.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Numbered alpha releases incorrectly use the stable publish job · New
• Versioned artifacts conflict with post-merge version bump plan · New

Resolved since last review (3)

• Update README CDN references to version 4.5.2
• Correct misspelled Assets heading
• Duplicate v4.5.2 changelog entry with empty comparison

[hitesh-shetty-cstk]

Re-review after new commits (pass 2 of 4).

Automated review

What this changes: Nothing under src/ moved since the last pass. The delta is release tooling, arriving through two sync merges from main plus the version bump. npm-publish.yml is rewritten into separate publish and publish-alpha jobs triggered on release: published, npm-alpha-publish.yml is deleted, the coverage action is pinned to a commit sha, CODEOWNERS is rewritten, prepack now runs the build so dist ships in the tarball, and package.json with the README CDN pin move to 4.5.3.

Business impact: The release path, which is the one journey here that reaches customers directly. Worth stating up front: every workflow and CODEOWNERS commit in this delta is already on main and byte identical there, so this PR carries them down to stage_v4 rather than introducing them. It still matters, because v4.5.3 is cut from this branch. The blocker below does not affect v4.5.3. It affects the next prerelease, which under this repo's own tag convention would publish to the latest dist-tag and reach every consumer on a caret range, including the esm.sh snippet in the README.

Security: nothing beyond what the scanners cover. Three things I checked rather than assumed, since the publish job lost its NODE_AUTH_TOKEN in this delta:

• The tokenless shape is not a break. v4.5.2 published through this same workflow on 16 September, and the follow-up hotfix that restored the build proves the publish step ran and authenticated. OIDC trusted publishing is configured and working, which is also why id-token: write and the npm upgrade step are there.
• persist-credentials: false and pinning the checkout to release.tag_name are both narrower than what they replace.
• The one moving dependency left in the release path is npm install -g npm@latest, flagged inline as a nit.

Flow

flowchart TD
    A[GitHub Release published] --> B{"release.name ends with -alpha?"}
    B -- "false" --> C["publish job<br/>npm publish --provenance"]:::changed
    B -- "true" --> D["publish-alpha job<br/>npm publish --tag alpha"]:::changed
    C --> E[latest dist-tag]
    D --> F[alpha dist-tag]
    G["release titled v4.6.0-alpha.0<br/>or left untitled"] -.-> H[gate reads false]:::risk
    H -.-> C
    classDef changed fill:#fff3cd,stroke:#d39e00
    classDef risk fill:#f8d7da,stroke:#c82333

Loading

Findings: 1 blocker, 0 should fix, 1 nit. Both are inline on .github/workflows/npm-publish.yml.

Copilot posted the same alpha routing finding on this head a few minutes before this pass. I have kept mine because it adds the untitled-release case and the provenance note, not to restate the part it already covers. Its other open finding, about the version bump conflicting with the post-merge plan, is answered by the description as it now reads, which lists the bump as done and the release as the next step.

Two things I looked at and am not raising:

• The changelog now carries a proper v4.5.3 section with a real compare link, so the duplicate heading from the earlier pass is gone.
• CODEOWNERS moves blanket ownership from visual-preview-developers to ghost-pr-reviewers and puts .github/workflows/ and CODEOWNERS itself behind the security team. That is a review governance change rather than a code defect, so it is a note rather than a finding, but it is the kind of thing worth being deliberate about since it changes who is pulled onto every future PR here.

Reviewer candidates: none requested. Reviewer assignment runs on the opening pass only, and this is pass 2. For the record, the release workflow in its current form is @Aravind-Kumar-cstk's (both consolidating commits) and @kirtesh-cstk's (the --tag alpha fix that the blocker extends). @kirtesh-cstk has already reviewed this PR, so the blocker is landing in front of the right person without a new request.

Not covered: I did not run the tests, the build, or the type check, and I cannot exercise a release without cutting one. I did not verify that the pinned vitest-coverage-report-action sha corresponds to the v2.13.0 tag in the comment beside it, because that repository is outside what I am allowed to read. I could not inspect the trusted publisher configuration on the registry side, so the conclusion that OIDC works rests on v4.5.2 having shipped through this workflow rather than on the npm settings themselves.

Automated review by Claude Code. A human review is still required.

---

Generated by Claude Code

[kirtesh-cstk]

LGTM

[karancs06]

LGTM!!