Skip to content

docs: explain the warning about undelivered JavaScript invocations - #6099

Open
mshabarov wants to merge 1 commit into
mainfrom
docs/undelivered-js-invocations
Open

mshabarov wants to merge 1 commit into
mainfrom
docs/undelivered-js-invocations

Conversation

@mshabarov

Copy link
Copy Markdown
Contributor

Documents vaadin/flow#25252

memory leak · flow/component-internals, flow/production ·
applications that schedule executeJs() from background threads or for
components that are not on screen

JavaScript scheduled on the server is held in memory until it's written
into a response for the browser, so an application that keeps
scheduling invocations which never reach the browser runs out of
memory. Flow now logs a warning once 1000 of them are waiting for one
UI. Nothing in the docs described the retention, the warning, or the
alternatives, and the symptom is hard to recognize from a heap dump.

Risks:

  • ✅ Docs only. One new section and one troubleshooting entry, no
    moved anchors.

  • Added an "Undelivered Invocations" section to Calling JavaScript from
    the Server, with the anchor undelivered-invocations.

  • Listed the three cases where invocations pile up: a detached owner,
    an invisible owner, and a UI with no open push connection.

  • Listed the alternatives for values where only the latest one matters:
    cancelExecution() on the returned PendingJavaScriptResult,
    Element.setProperty(), and UI.getLastUpdateSentTimestamp() to
    stop scheduling while the browser isn't receiving.

  • Added an entry to Common Issues on the production troubleshooting
    page, pointing at the new section.

🤖 Generated with Claude Code

Scheduled invocations are held in memory until they are written into a
response, so an application that keeps scheduling ones that never reach
the browser runs out of memory. Flow now warns about it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@peholmst peholmst added the target/v25.3 Automatically cherry-pick to the v25.3 branch label Sep 21, 2026
Where only the latest value matters -- a progress value, a clock, a live measurement -- avoid scheduling a new invocation for every update:

- Keep the [classname]`PendingJavaScriptResult` that [methodname]`executeJs()` returns, and call [methodname]`cancelExecution()` on it before scheduling the next one.
- Set an element property with [methodname]`Element.setProperty()` instead. Only the last value of a property is sent.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems not clear to me how element properties are related to pending JavaScript invocation. Do we have documentation that suggests setting properties via JavaScript?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

target/v25.3 Automatically cherry-pick to the v25.3 branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants