Persistent API Calls After Cells Kernel Shutdown

[MarcosVn]

Description

I have my own custom Notebook.tsx component that uses the Cell.tsx set from jupyter-react

• a very similar version - with just a few enhancements - compared to what I documented in What is the best way to ensure the shutdown of a kernel before initializing a new one? #338.

Currently, every time a user accesses this notebook, we create a kernel, and upon exiting, we shut it down (to maintain a unique context per notebook, similar to the JupyterLabApp).

One issue we have today (and would like to confirm) is that even after a user leaves Notebook X, meaning they are no longer inside the component and the associated kernel has been shut down, requests to /jupyter-server/api/sessions?{id} and /jupyter-server/api/kernels?{id} continue to be made continuously (and these likely accumulate as we have N notebooks with N cells).

From some tests, I noticed that this seems to occur even in the ./src/examples/Cells of the library.

Is this a known issue, and is there any way to control these calls?

Reproduce

1. Create a wrapper over Cells.tsx example;
2. Leave the component (navigate to another route/context) and observe the requests still being made.

Expected behavior

Have better control over these requests

Context

• Datalayer version: 0.17.2

• Browser and version: Chrome Version 130.0.6723.116

• Current unmount code:

notebookStore.reset(id).finally(() => {
   kernelManager?.shutdown(kernel.id).then().finally(() => {
     console.log(`Kernel ${kernel?.id} is turned off`);
    });
});

• From our custom Notebook.tsx:

• From jupyter-react ./src/examples/Cells:

[echarles]

Yeah, I have seen that difficulty to really teradown the jupyterlab services. We are leading towards fully serverless components, and ensure better lifecycle management. TBH that difficult is mainly generated by the upstream jupyterlab being not always like it should be. Also, I can spend time to debug/fix on main branch, but won't be able to look at 0.17.x specifics.

[MarcosVn]

Hey @charles,
Posting some updates based on tests done here:

• The issue also occurs in 0.19.x (main);
• I tested it in Notebook.tsx example from lib and it also seems we don’t have this control there (even though we’re not using this component in our use case);
• I did some tests adding extra disposes in my unmount, like the ones below, but it doesn’t seem to be enough. It’s as if some process started by the Adapter is still running in the background.

kernel.session.dispose(); 
kernel.connection?.dispose();
serviceManager?.kernelspecs.dispose(); 
serviceManager?.sessions.dispose(); 
serviceManager?.dispose();

I’ll keep investigating and testing as soon as possible, but if you have any idea how to stop this (even if it’s not an ideal approach), please let me know.

[echarles]

Hi @MarcosVn I have gone though that journey some time ago to finally move over without solution. There maybe something wrong in the upstream jupyterlab. There is an option you can provide when the ServiceManager is created that could maybe help based on your use case.

    /**
     * When the manager stops polling the API. Defaults to `when-hidden`.
     */
    standby: Poll.Standby | (() => boolean | Poll.Standby);