model-apps: re-vendor the SDK bundle (blocked only by one stale contract test; needs live verification)

[akshaymaloo]

Plugin

model-apps

Summary

The vendored SDK bundle (plugins/model-apps/scripts/vendor/cds-maker-sdk.cjs) is behind the first-party SDK. A re-vendor is a one-test change — but it needs live verification before it ships, which is why this is an issue rather than a PR.

Filing because the diagnosis below was previously only in a reviewer's local notes, and it corrects an earlier claim that three contract tests blocked the uptake.

Reproduce

# 1. build the SDK (from packages/cds-maker-sdk in the first-party repo)
npm run build

# 2. re-vendor (from this repo's root)
node plugins/model-apps/scripts/_vendor-build/build.js --sdk <path-to-sdk-repo>
#    -> 572 KB -> 616 KB

# 3. run the suite
cd plugins/model-apps && node scripts/run-tests.js

Result: 1 failure, not three. The other two previously suspected (pushArtifact 412 signalling) do not reproduce.

The single failure is a stale test, not an SDK problem

scripts/tests/vendor-sdk-smoke.test.js pins the OLD deleteAppCascade contract — that a failed cascaded generative-page delete sets success=false and lands in failures[].

The newer SDK deliberately does not cascade generative-page deletes at all. A uxagentproject is referenced by an app, not owned by one (another app's sitemap, or a form's UxAgentControl RefId, can point at the same row), so it reports the page in a new retained[] array and leaves the decision to the caller. Probed against the re-vendored bundle:

{ "success": true, "deleted": [{"type":"app"}], "failures": [], "retained": [{"type":"genPage"}] }

with no DELETE attempted against the page.

scripts/lib/sdk-teardown.js is already written for this — its comments name retained explicitly and it deletes only the pages the build's own page manifest records as authored, letting Dataverse's dependency graph reject anything still referenced. Only the contract test lagged behind the code.

With the test updated to pin retained[], the full suite is 1499 pass / 0 fail on the new bundle.

Why this is not just a PR

Offline tests use mocks, so a green suite does not prove the new bundle behaves correctly against real Dataverse. A re-vendor changes runtime behaviour across every phase — build, verify, teardown, genpage. Before merging it needs a live end-to-end run (build → verify → teardown) on a real environment, at minimum covering the artifact phases the contract tests only mock.

Work required

1. Re-vendor and commit the bundle.
2. Update the deleteAppCascade contract test to assert retained[] — keep it pinned, since silently reverting to a cascade would delete a page another app still surfaces.
3. Live end-to-end verification on a real environment.
4. Diff the SDK changelog between the vendored version and HEAD for behaviour changes the contract tests do not cover.

[akshaymaloo]

Status update — this is done in #458, and the "blocked by one stale contract test" framing turned
out to understate the work considerably.

The re-vendor now comes from the merged master tip, not a feature branch, so the committed
bundle is reproducible from a commit. That mattered more than expected: the bundle previously
committed here could not be reproduced from any current source. It still contained
ARTIFACT_CACHE_PREDATES_SESSION, which is absent from both the merged tip and the feature branch —
i.e. it had been built from a stale lib/ output, several upstream commits behind its nominal
source.

The real blocker was not a stale test. Building from the merged tip surfaced a breaking upstream
change: session-cache enforcement was replaced by a 300 s staleness window with revalidating
reads, which made seven public methods asynchronous —

addElement, findElements, getArtifact, moveElement, queryTree, removeElement, updateElement

The plugin had 40 un-awaited call sites, and the failure mode is silent rather than a crash. A
promise is truthy, so the engine's || {} guards never fire and the pure artifact helpers receive a
promise instead of a form: hasSubgrid → false (duplicate sub-grid on rebuild), hasQuickView →
false (duplicate quick-view), formFieldLogicals → [] (every spec field looks missing, so all
are re-added), findFieldCellPointer → null (an explicit-layout removal never lands). Wrong
artifacts on a real environment, behind 2xx responses and a green build.

Only 4 of ~1590 tests caught it, for two independent reasons, both now fixed:

1. Every test mock's generic surface returned plain values while the real SDK returns promises, so a
   missing await behaved identically under the mock. ~1500 mock-driven tests were structurally
   blind to the class.
2. No test exercised a rebuild. Every reconcile test started from an empty deployed form, where
   "re-add everything" and "add only what's missing" produce identical call logs.

Live verification. Done read-only against a real environment rather than by writing to one: a
stock account main form was fetched through the re-vendored bundle, and the plugin's helpers were
run over the real payload. Awaited, they read 24 fields and located the cell pointer; un-awaited,
the same helpers returned [] and null — the silent-corruption mode reproduced live on real
server data. No writes were issued.

Regression nets added: a source scan that fails on any un-awaited call (mutation-tested — red on
three separate un-await mutations of the engine), a dynamic check that the bundle still returns
promises for exactly that method list, async mocks that actually yield, a two-pass rebuild
idempotence test, and concurrency stress on the shared workspace manifest.