Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix the activity and execution-state tracking for kernels.
This commit changes the way Jupyter server tracks both activity and execution state so that both of those are based solely on user actions rather than also incorporating control messages and other channels. This is important for both correctly tracking the state of the kernel, and also for culling kernels. Previously, the last activity timestamp was updated on every message on the iopub channel regardless of the type of message, and execution state was based on every `status` message on that channel regardless of what other message the `status` was in response to. That behavior causes incorrect behavior for both kernel culling and kernel status. In particular, it can result in both kernels being culled too early and too late (depending on what the user is doing). For example, if a user ran a long running code cell, and then switched tabs within the JupyterLab UI, then the JupyterLab UI would send a control message to the kernel and the kernel would respond with a status message referencing that control message as its parent. As a result of that, the Jupyter server would update its execution state to be `idle` even though the long running code cell was still executing. This could cause the kernel to be culled too soon. Alternatively, if the user was not running anything and just switched tabs within the JupyterLab UI, then the last activity timestamp would be updated even though the user didn't run any code cells. That would cause the kernel to be culled too late. This change fixes both of those scenarios by making sure that it is only user actions (and kernel messages in response to those user actions) that cause the execution state and last activity timestamps to be updated. This initial commit contains just the code change so that I can solicit feedback on this proposed change early. The core of the change will have to be new tests, which will come in a subsequent commit as part of the same pull request.
- Loading branch information