[ZEPPELIN-6638] Time out the React remote entry load - #5409
Open
kimyenac wants to merge 1 commit into
Open
Conversation
ReactRemoteLoaderService settles loadContainer() only from the script tag's onload and onerror. Neither fires while a request is merely pending, so a remoteEntry.js request that is accepted and never answered leaves the promise pending for as long as the browser holds the connection. onError is never called, and the hosts that depend on it never fall back: the paragraph footer keeps an empty mount div instead of restoring the Angular footer, and the published paragraph renders nothing. Bound the script load with environment.reactRemoteLoadTimeoutMs and reuse the existing fail() path on expiry, which removes the tag and leaves the caches drained so a later mount can retry. Set it to 0 to disable the timer. The chunks that container.get() pulls are left alone. They are fetched by the remote's own webpack runtime, which already bounds them with output.chunkLoadTimeout, and a second shorter timer would cut off a multi-megabyte chunk on a slow connection. Covered by two Playwright cases: one that holds remoteEntry.js open without ever answering and asserts the Angular footer comes back, and one with a delayed but successful response that asserts the React footer still renders.
kimyenac
force-pushed
the
ZEPPELIN-6638
branch
from
August 10, 2026 07:55
7c84d45 to
dfdfc3f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR for?
ReactRemoteLoaderServicesettlesloadContainer()only from the script tag'sonloadandonerror. Neither fires while a request is merely pending, and there is no timer. AremoteEntry.jsrequest that the server accepts and never answers therefore leaves the promise pending for as long as the browser keeps the connection open, which is minutes.onErroris never called, so the hosts that depend on it never fall back. The paragraph footer keeps an empty mount div instead of restoringzeppelin-notebook-paragraph-footer, and the published paragraph renders nothing. Both look like a slow page rather than a failed load.This bounds the script load with
environment.reactRemoteLoadTimeoutMs(10 s, or 0 to disable) and reuses the existingfail()path on expiry, which removes the tag and leaves the caches drained so a later mount can retry.The chunks that
container.get()pulls are left alone. They are fetched by the remote's own webpack runtime, which already bounds them withoutput.chunkLoadTimeout(120 s by default). A second, shorter timer over that path would cut off a multi-megabyte chunk on a slow connection, which is a worse failure than the one being fixed.What type of PR is it?
Bug Fix
Todos
None
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-6638
How should this be tested?
e2e/tests/notebook/paragraph/react-footer.spec.ts: one holdsremoteEntry.jsopen without ever answering and asserts the Angular footer comes back, one answers after a delay well inside the budget and asserts the React footer still renders. The first fails on master and passes here; verified by setting the budget to 0, which reproduces the current behaviour and makes it fail.e2e/tests/notebook/published/published-paragraph.spec.ts, for regressions. Chromium, all green.npm run build).@Injectabledecorator, which the current setup cannot compile. Left to a follow-up once that lands.Screenshots (if appropriate)
No
Questions:
projects/zeppelin-react/README.mdis updated in this PR