I have an idea what the point is of the heartbeat mechanism, but I think that the actual implementation has no sense at all. When the processing of an ordinary request has been finished, then the vaadin service calls the requestEnd method where the handling of the heartbeat timeout happens. If the processing of that request took too much time (more than 3.1 * heartbeatInterval), then vaadin sometimes closes the UI. Sometimes, because there is a time gap between the session unlock, and the checking of the heartbeat timeout, so there is a chance to that the enqueued heartbeat request be processed.
If a request finished, that means that the UI is alive, the server gets requests. Why has to be closed a living UI and session?
The point of the heartbeat mechanism is remove other UIs in the same session that are no longer active, not the one that has the current request going.
I don’t think you should ever have single requests take longer than 3.1 * heartbeatInterval. Either you should reduce the duration of your requests (by moving heavy computation to a background thread) or increase your configured heartbeat interval - I take you have set it to some much smaller value than the default 5 minutes?
Anyway, yes, in theory the current UI should probably be exempt from the cleanup, or the timestamp should be set at request end, so what you described couldn’t happen even in theory. However, I strongly recommend you consider my suggestion above. If you do have a use case for this, please
open a new enhancement request
in the issue tracker.