SCAL-336321 Order the pre-render show cycle, and always state its runtime filters

[sastaachar]

Problem

On a shared pre-render, a runtimeFilters value from one liveboard sticks when the host switches to another liveboard, and runtimeFilters: [] does not reset it. The container fix attempted in blink-v2 ([SCAL-333947], PR #68332) did not close it and has been reverted.

There are three independent causes. The host events go out in the wrong order, the payload never says "no filters" in a way the container reads, and a same-route show never unmounts the liveboard that is holding the stale state.

Cause 1 — the host events go out in the wrong order

LiveboardEmbed.beforePrerenderVisible() queues two container-ready callbacks:

1. super.beforePrerenderVisible() → posts HostEvent.UpdateEmbedParams
2. its own → posts HostEvent.Navigate

Both are invoked in registration order, but the first one suspends on await this.getUpdateEmbedParamsObject() (which awaits getAppInitData()). It yields at that await, callback 2 runs to completion, and the real order on the wire is:

["Navigate", "updateEmbedParams"]

That is observed output, not a reading of the code — it is what the new test records when the fix is removed.

So the container starts loading the new liveboard while still holding the previous config's runtimeFilterParams, and the params that arrive mid-load are dropped.

Fix

TsEmbed.beforePrerenderVisible() now publishes preRenderParamsApplied, a promise that resolves once UpdateEmbedParams has been posted and the container has had UPDATE_EMBED_PARAMS_SETTLE_MS (200ms) to apply it. LiveboardEmbed awaits that before triggering Navigate.

The settle window is deliberate rather than an ack-wait: the container applies the payload through React state, so the post being delivered is not the same as the new params being in effect, and awaiting trigger() would risk stalling navigation on the 30s trigger timeout.

Two properties worth checking in review:

• the promise is created synchronously in beforePrerenderVisible(), outside executeAfterEmbedContainerLoaded, so the navigation callback has something to await whether the container is already loaded or not;
• it resolves in a finally, so a params failure delays navigation but never blocks it. Both callbacks are gated on the same container-ready signal, so neither can strand the other.

Cause 2 — nothing in the payload says "no filters"

The payload carries runtime filters in two fields:

field	what it is
runtimeFilters	the raw array, present only because the payload spreads the view config
runtimeFilterParams	the serialized col1=…&op1=…&val1=… string — what the container reads

getDefaultAppInitData() builds the serialized form from viewConfig.runtimeFilters, and only when excludeRuntimeFiltersfromURL is set, because a URL render puts the filters in the iframe's query string instead. A show cycle has no URL to put them in. So a config that declares no filters sent this:

{
  "runtimeFilterParams": null,   // ← the field the container reads
  "runtimeFilters": undefined
}

and the container's handler is:

if (embedConfigFromEvent.runtimeFilterParams) {
    const parsedFilters = {};
    parseQueryParams(embedConfigFromEvent.runtimeFilterParams, parsedFilters);
    updateRuntimeFilterParams(parsedFilters);
}

null is falsy, so the branch never runs and the container keeps the previous embed's runtimeFilterParams state. getRuntimeParams then prefers that state over embedParams:

const embedRuntimeFilter = !_.isEmpty(runtimeFilterParams) ? runtimeFilterParams : embedParams;

so the stale value outranks the freshly-rebuilt params on every show. That is the filter that sticks.

Fix

The show-cycle payload now always states both — this config's serialized, or '&' when it declares none:

return {
    ...this.viewConfig,
    ...queryParams,
    ...appInitData,
    runtimeFilterParams: serializeRuntimeFilters(this.viewConfig.runtimeFilters),
    runtimeParameterParams: serializeRuntimeParameters(this.viewConfig.runtimeParameters),
};

runtimeParameterParams has the identical shape — same truthy gate at embed.container.tsx:192, same !_.isEmpty(embedParameterParams) ? embedParameterParams : embedParams fall-through, and getRuntimeParameterInput({}) breaks on a missing param1 exactly as the filter reader breaks on a missing col1. So a config declaring no parameters left the previous embed's standing, just as its filters did. The December 2025 container change broke both; only the filters were reported.

One difference: no segment trimming for parameters. A parameter always has both halves of its pair, and paramVal1= is an empty-string value rather than an absence — there is a test pinning that it does not collapse to the empty marker.

The same is true of runtimeParameterParams, updateEmbedParameterParams and getRuntimeParameterInput.

Why '&' and not null or ''. Both falsy forms read as "no news" at that gate and leave the previous filters standing. A lone separator is truthy, so the branch fires — and new URLSearchParams('&') yields no pairs (the urlencoded parser skips empty sequences), so parsedFilters is {} and updateRuntimeFilterParams({}) replaces the state with an empty object. _.isEmpty({}) is then true, so the container falls through to embedParams — which updateEmbedParams(processedParams) has just replaced, from this same event, with this config's params. A config with no filters contributes no col1, getRuntimeFilterInput breaks on the first iteration, and the result is [].

Both updateRuntimeFilterParams and updateEmbedParams are plain useState setters (embed.container.tsx:66,77), so each is a replace, not a merge — that is what makes the fall-through safe.

What this removes

Stating the filters outright means the SDK never has to work out what the previous embed's were. So the earlier revisions of this branch are gone:

• the preRenderConfig.reconcileRuntimeParams flag — deleted, not defaulted on. There is nothing left to opt into: no extra host events, no extra traffic, one field in a payload that was already being sent.
• getPredecessorViewConfig() and the predecessor capture — deleted. The clear-by-empty-values approach they existed for needed to name the predecessor's columns, and correctness then depended on the predecessor chain being right across every A → B → C hand-over.
• the follow-up HostEvent.UpdateRuntimeFilters / UpdateParameters posts — deleted. They re-sent values the payload already carried, and added a second ordering question next to Navigate.

Net −119 lines against the previous head of this branch.

It also closes runtimeFilters: [], flagged as an open question on the earlier revision: it serialized to null before, and now reads as empty like any other config with no filters.

takeOverPreRender() stays — see below. It is carrying two bugs of its own.

Pre-render ownership

preRenderWrapper[__tsEmbed] was written only in handleInsertionIntoDOM(), i.e. by the instance that creates the pre-render, and never moved, so getPreRenderObj() meant "the creator", not "what is showing". showPreRender() now ends with takeOverPreRender(), which repoints the wrapper at the instance being shown. connectPreRendered() adopts the state that belongs to the shared iframe, beside inheritPreRenderContainer().

That hand-over exposed a latent trap worth reviewing carefully. isEmbedContainerLoaded was set per instance, by whichever ones were subscribed when the container announced itself — and hidePreRender() unsubscribes. An instance hidden before the container came up reports false forever, and once it owned the wrapper it handed that false to everyone after it: UpdateEmbedParams never fires, preRenderParamsApplied never resolves, Navigate never goes out, getCurrentContext() hangs. Permanently, silently. The flag now lives on the wrapper node, where it belongs — it describes the iframe, not an instance. The regression test for it was verified to fail without that change.

LiveboardEmbed also now writes currentLiveboardState on itself rather than on the instance it took over from, so "current" is true of the owner again.

Cause 3 — a same-route show never unmounts the liveboard

Showing the same liveboard again through the shared pre-render (LB1 → LB1) sent a Navigate to the route the container was already on, which its router treats as a no-op. The liveboard component was never unmounted, so it kept everything it had accumulated — filter chips the user had moved, selections, the active tab — and UpdateEmbedParams was left as the only thing carrying the new values into a component that had already made up its mind.

Fix

That show now goes lb → home → lb. Home unmounts the liveboard; the Navigate that follows rebuilds it from the UpdateEmbedParams posted just before.

await this.preRenderParamsApplied;
if (this.isShowingLiveboardRoute(showing)) {
    await this.clearLiveboardStateViaHome();
}
this.navigateToLiveboard(…);

Three things worth review:

• The comparison is the whole route, not the liveboard id. The path is built from the viz, tab and personalized view as well, so a same-liveboard show that moves to another tab is a real navigation and must not be diverted through home. There is a test for exactly that.
• What the container is showing is read from the predecessor's currentLiveboardState, captured synchronously in beforePrerenderVisible() — showPreRender() calls takeOverPreRender() afterwards, so by the time the async callback runs getPreRenderObj() names this instance instead. It diverts only on a positive match: an unknown predecessor takes the ordinary path, since a plain Navigate to a route the container is not on does the unmounting by itself.
• A self-takeover is left alone. When the predecessor is this instance, the embed is being hidden and shown again rather than handing over, and the state the liveboard holds is its own — the filter chips this user moved on this liveboard. Clearing that would throw away their session for a visibility toggle, so the predecessor is compared against this before its route is read.
• The home hop waits a settle window, not an ack. The container does not acknowledge Navigate, so awaiting that trigger does not resolve on the route change — it resolves when TRIGGER_TIMEOUT fires. An earlier revision of this branch did await it, and parked the re-shown liveboard on the home page for a full 30 seconds: Navigate home at 18:55:56, the liveboard back at 18:56:26, measured on a cluster. It now posts home and waits HOME_UNMOUNT_SETTLE_MS (200ms), the same reasoning and magnitude as the params window. The wait is still needed — both routes in one tick invites the router to coalesce them, leaving the liveboard mounted — but it is bounded by us rather than by a timeout. The trigger keeps a catch so its eventual rejection is not an unhandled promise, and a failure warns and carries on: stale state beats a liveboard that never comes back.

Verification

• Ordering test is proven to have diagnostic power: with await this.preRenderParamsApplied removed, should trigger Navigate only after UpdateEmbedParams has settled fails with the received array quoted above. It is not a test that passes either way.
• Same check on the empty marker: reverting serializeRuntimeFilters to return null for an empty list fails 4 tests and nothing else — the three "should mark the params empty…" cases and the hand-along chain. Dropping the runtimeParameterParams line fails its own case.
• The home round trip is pinned four ways, each mutation failing a different set: never diverting fails 2 tests, always diverting fails 3, dropping the self-takeover guard fails only the hide/show one, and going back to awaiting the ack fails the two settle tests. That last one is the 30s stall above, reproduced with a promise that never settles — which is what a real home hop looks like.
• Full SDK suite: 45/45 suites, 1768 passed, 4 skipped, no coverage threshold violations.
• tsc --noEmit clean; eslint 0 errors and no new warnings (20 on the touched files, same as baseline).
• Tests assert the exact serialized strings — col1=Color&op1=IN&val1=red&val1=blue for a declared filter, param1=Region%20Param&paramVal1=West for a parameter, '&' for none of either — and pin that no UpdateRuntimeFilters / UpdateParameters follows the payload.
• 8 existing pre-render tests were updated, not deleted: they asserted on the navigate spy synchronously, which is exactly the behaviour this PR changes. Each now waits out the settle window. The AuthInit test needed 1305ms rather than 1005ms — 1000ms container-ready fallback plus the 200ms window.

Notes for the reviewer

• '&' is the reviewable decision. It works because the container's gate is a truthiness check, and it is not a shape blink documents. If someone tidies it to '', the fix silently reverts with no blink-side test to catch it — hence the named constant and the comment at both the constant and the call site. The non-fragile version is a one-character container change, != null instead of truthy, which would let this be ''; worth filing against blink so this can be simplified later.
• Not verified on a cluster. The chain above is read from blink-v2 source (embed.container.tsx:190-207, runtime-filters.util.ts:267-295, embed-util.ts:718), not executed. The step most worth confirming by hand is new URLSearchParams('&') → no pairs → {}.
• The home waypoint is 'home', the same string AppEmbed sends for Page.Home. Worth a look from someone who knows whether a Liveboard-mode container renders anything visible at that route during the hop — a flicker would be the cost of clearing the state.
• One consumer falls back to the URL. runtime-filters.util.ts:390 ends embedFilter.length > 0 ? embedFilter : getRuntimeFilter(), so an empty result there reads filters off the iframe URL. V1Embed defaults excludeRuntimeFiltersfromURL: true, so the URL is normally bare and this lands on [] — but a customer who sets that flag false could see the creating embed's filters come back through PinboardAttributeFilterContainer.
• Pre-render code wants its own file. It is spread across TsEmbed — wrapper elements, ownership keys, lifecycle, positioning, and now the params contract — and two of the bugs fixed here came from state being owned by the wrong thing. Filed as SCAL-338011, with a TODO at the preRenderWrapper declaration. Refactor only, best done after this merges.
• Supersedes SCAL-333947 : Parma #654, which carries an earlier form of this change. Close that one in favour of this.
• Only LiveboardEmbed navigates its pre-render on show; AppEmbed does not override beforePrerenderVisible, so it is unaffected.

Refs SCAL-336321, SCAL-333947.

[gemini-code-assist]

Code Review

This pull request addresses race conditions in pre-rendered embeds by delaying navigation until the UpdateEmbedParams payload has settled and by reconciling runtime filters on shared pre-renders. The review feedback highlights two key improvements: safely guarding the .map() call on prevRuntimeFilters with Array.isArray to prevent runtime TypeErrors, and explicitly asserting the presence of UpdateEmbedParams in test assertions to avoid false positives from indexOf returning -1.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@thoughtspot/visual-embed-sdk@659

commit: 9523b05