Interaction Insights

The interaction collector listens to server-side RPC invocations — the client-to-server calls behind a button click, a value change, an @ClientCallable method, or a return channel — and retains two kinds:

A slow data load never reaches the interaction collector. The invocation that triggers it only registers a flush, so a combo box that takes four seconds to fetch a page ends its invocation in microseconds and never qualifies as a slow interaction. A second collector therefore watches the queries themselves, retaining the ones that threw and the ones that ran over the same 1000 ms budget — a query is part of what the user waits for, so it earns attention at the same point.

This one additionally requires vaadin.observability.data (on by default).

A script that fails in a tab reaches no server log at all. The in-browser collector reports uncaught errors and unhandled rejections, and a third collector retains what identifies each one: the kind, the script it came from, and the first stack frame. None of that is a number, and each would be one time series per distinct value, which is why it’s kept as an insight instead of as tags on the vaadin.client.errors counter.

This one additionally requires vaadin.observability.client (on by default), since the browser collector is what supplies the reports. A payload carries at most 20 browser-error insights, the most-reported first.

Browser errors have a page of their own: see Client Error Insights for what a report carries, what reaches its script location, how a report that waited out an outage is reported, and why the payload is capped.

Everything else is dropped. Retained records live in bounded in-memory ring buffers of vaadin.observability.insights-capacity entries each, 100 by default, and the oldest is evicted once a buffer is full. Interactions, queries, and browser errors are retained separately, so with all three active the total is three times the capacity. Keeping them apart means a burst of slow queries can’t evict the failed interactions, and neither can the flood of buffered reports that arrives when a network outage ends. Nothing is written to disk, and the buffers don’t survive a restart.

Collection is best-effort: if capturing a record fails, the error is swallowed rather than interfering with data loading or the framework’s own error handling.

applicationFrame is the first stack frame that isn’t framework code — the JDK, Vaadin, Spring, Hibernate, the servlet container, and bytecode generators are all skipped — so it points at the application code most likely to hold the bug. The exception reported is the root cause, not the wrapper.

The replay steps above are the production form, which names the component by its class. In development mode they name it by its caption and list the state the view was in; see Replay Steps That Replay.

The headline number is the median, not the worst case, so a single outlier doesn’t describe a group that’s only just over budget. Note what measures says: the duration is server-side invocation handling alone, so what the user actually felt is at least this much.

A query insight describes a load rather than a user action, so its evidence carries a range and a row count where an interaction carries a DOM event and a stack frame:

queryKind is fetch for a query loading one page of items, or count for one asking how many items a level holds. filtered separates a combo box loading matches for typed text from one loading the whole data set.

The remaining evidence depends on the kind. A fetch reports requested against returned, which is where over-fetching and short pages show up. A slow count reports counted instead — the total it arrived at — because "took four seconds" is far less actionable than "took four seconds counting 2,000,000 items".

A failed query is reported the same way as data-query-error, with an exception field holding the root cause and no duration figures. Query insights carry no suggestion or applicationFrame: the failing code is the data provider the component was given, which the kit can’t name from the query alone.

Each insight carries up to three of its most recent occurrences. For an interaction:

location is the concrete path, as opposed to the template the insight groups on. sessionId is a short one-way hash by default: enough to tell whether three occurrences came from one user or three, without identifying the session. stackTop is present only when detail collection is enabled.

A query example is keyed differently — at rather than timestamp — and reports the range it asked for instead of a session:

The offset, limit, and rows fields are present for a fetch and omitted for a count.

The state is a snapshot, not a history. Reading the values once, when the failure is captured, gives each field once, as it actually stood, in the order the user last changed them. Accumulating what the user did as they did it isn’t equivalent: picking one item out of a Select arrives as three RPC invocations (opened-changed, value-changed, opened-changed), none of them an instruction anyone can carry out, and a user who changes their mind leaves the same field in the list twice with the stale value first.

What goes into the snapshot is every component in the view that holds a value, has a caption, and the user actually changed. The last of those is what keeps the list short: a replay starts from a freshly opened view, so a field nobody changed is already at the value the reader finds there, and telling them to set it is a line that says nothing. Only identity is remembered as the user works, never values; the values are read once, at capture.

"Changed" is decided by comparing the field’s value across the invocation, not by the event that carried it, so merely opening a dropdown doesn’t report it. The exception is a synchronized property update: Flow applies the new value to the whole request’s state before it reports any invocation, so there’s nothing left to compare by then, and an mSync reaching something that holds a value is taken as a user edit.

The value is read from the component rather than from the property the client sent, so a Select says 'Defective' and not the item key '2'. A field the user emptied becomes Leave the 'Order number' TextField empty, which is worth a line because a blank value is frequently the whole bug. A value whose only text is a default toString() — com.example.Order@6f2b958e — is left out, since nobody can type that into a field. At most ten values are reported per insight.

The scope is the view, not the page: the innermost route target holding the interacted component, so an application’s shell — its navigation, its app switcher — stays out. The shell is on screen throughout, has nothing to do with the failure, and would otherwise put the same lines in every insight the application produces. For a component the route target doesn’t hold, such as a dialog or overlay the UI owns directly, the scope is that component’s own top-level ancestor, which is the screen the user was actually looking at.

There are two things this doesn’t capture. A failure that needs a sequence rather than a state, such as clicking "Add line" twice: the state says what the view held, not how it got there. And a value the application set as a side effect of something the user did, such as picking a customer auto-filling their address, since what’s reported is what the user worked.

Grouping is unaffected. Occurrences still group by route, component, event, and exception, so the same failure hit with different values stays one insight, reporting the values of its most recent occurrence.

Captions and values are withheld in production, where the steps fall back to the form at the top of this section, and no setting turns them on there. They’re application text that can be data-bound — a caption may read "Delete Jane Doe", and a field’s value is user input by definition — while the insights payload is built to be forwarded into issue trackers and AI agents. The reader who benefits from the detail is the developer with the application in front of them, so that’s the only mode that collects it.

Lengths are capped regardless: 60 characters for a caption, 40 for a value.

"3 findings need attention" is only worth reading while all three are news, so two kinds fold away behind a collapsed line under the list — "2 hidden findings", "3 findings gone quiet", or "5 findings set aside (2 hidden, 3 gone quiet)":

Nothing is discarded. The fold always shows how many findings are behind it and which of the two reasons put them there, and one click renders them, faded, with their detail and replay intact.

The panel keeps watching with its window closed, and a finding the payload didn’t have before is written to the Copilot log, deduplicated on the same grouping key the endpoint uses, so one problem notifies once however often it recurs. Announced are the findings the current page raised — anything first seen since it loaded, including during the load itself, so a slow query on the landing view is reported. The older records in the buffers, which outlive a reload, aren’t. A finding you hid isn’t announced either.

Findings need vaadin.observability.insights together with errors or requests, and client for browser errors — all on by default. With any of them off, the panel says that insights aren’t being collected rather than showing an empty list. Nothing here exists in production, where neither Copilot nor the dev-tools connection does.