Title: Kernel Gateway sends `input_request` with inconsistent session ID, causing kernel to hang on input()

[shakhbanov]

I am encountering a persistent issue where the Jupyter Kernel Gateway appears to send input_request messages with a session ID that is different from the session ID used in the initial execute_request. This inconsistency prevents the client from correctly replying to the input prompt, leading the kernel to hang in a "busy" state indefinitely.

Steps to Reproduce:

1. Client Setup: A web-based IDE (HTML/JavaScript) establishes a WebSocket connection to Jupyter Kernel Gateway.
   • The client successfully creates a new kernel via POST /api/kernels and receives a kernelId (e.g., 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e).
   • The client connects to the kernel's channels WebSocket using this kernelId.
2. Code Execution: The client sends an execute_request message with its header.session set to the established kernelId (e.g., 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e).
   • Example Code Executed:

     print("Part 1: This output works.")
     my_input = input("Enter something: ")
     print(f"Part 2: You entered: {my_input}")
     2 + 2

3. Inconsistent input_request (Server-side issue):
   • The Kernel Gateway processes the execute_request associated with session: 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e.
   • However, when the input() function is encountered, the Kernel Gateway sends an input_request message (and other subsequent messages like status, stream) to the client with a DIFFERENT header.session ID (e.g., c06b037c-7f03eeb634ab6e033f8bb7d0).
4. Client Reply Attempt:
   • The client correctly receives this input_request and stores its header as parent_header.
   • To reply, the client crafts an input_reply message:
     • header.session is forced to be the client's original kernelId (e.g., 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e) in an attempt to work around the inconsistency.
     • parent_header is set to the header of the received input_request (thus, parent_header.session is c06b037c-7f03eeb634ab6e033f8bb7d0).
5. Kernel Hangs: Despite the input_reply being sent, the kernel remains in a busy state, and the execution does not proceed past the input() call. This indicates that Kernel Gateway is not correctly associating the input_reply with the pending input_request.

Expected Behavior:

The session ID in messages sent by Kernel Gateway (e.g., input_request, status, stream) should consistently match the session ID of the execute_request that initiated the execution, or the kernelId of the WebSocket connection. The input_reply should then be processed correctly, allowing the kernel execution to complete.

Observed Behavior (with relevant log snippets):

Kernel Gateway Logs:

[19:08:06] [KernelGatewayApp] WARNING: No channel specified, assuming shell: {'header': {'msg_id': '0c3f0539-b9f4-4bf4-92f2-93d94e162abd', 'session': '8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e', 'date': '2025-07-31T19:08:06.673Z', 'msg_type': 'execute_request', 'version': '5.3'}, 'parent_header': {}, 'metadata': {}, 'content': {'code': 'print("Part 1: This output works.")\nmy_input = input("Enter something: ")\nprint(f"Part 2: You entered: {my_input}")\n2 + 2', 'silent': False, 'store_history': True, 'user_expressions': {}, 'allow_stdin': True, 'stop_on_error': True}, 'buffers': []}
[19:08:06] [KernelGatewayApp] DEBUG: activity on 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e: status (busy)
# ... (other messages from KG, e.g., stream, input_request, all with header.session: c06b037c-7f03eeb634ab6e033f8bb7d0) ...
[19:08:09] [KernelGatewayApp] WARNING: No channel specified, assuming shell: {'header': {'msg_id': '7d9b49dd-74bc-4c0d-a551-ab6f64b74d61', 'session': '8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e', 'date': '2025-07-31T19:08:09.388Z', 'msg_type': 'input_reply', 'version': '5.3'}, 'parent_header': {'msg_id': 'c06b037c-7f03eeb634ab6e033f8bb7d0_3367_13', 'msg_type': 'input_request', 'username': 'username', 'session': 'c06b037c-7f03eeb634ab6e033f8bb7d0', 'date': '2025-07-31T19:08:06.947924Z', 'version': '5.3'}, 'metadata': {}, 'content': {'value': 'Python', 'status': 'ok'}, 'buffers': []}

Client-side Browser Console Logs:

Ядро создано. Новый kernelId: 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e
python-4.html:796 Веб-сокет подключен к ядру: 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e
python-4.html:1052 Отправлено сообщение execute_request: 0c3f0539-b9f4-4bf4-92f2-93d94e162abd для session: 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e
python-4.html:803 [WS_MESSAGE] Type: status, Session: c06b037c-7f03eeb634ab6e033f8bb7d0, KernelId (client's): 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e
python-4.html:803 [WS_MESSAGE] Type: input_request, Session: c06b037c-7f03eeb634ab6e033f8bb7d0, KernelId (client's): 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e
python-4.html:904 Получен input_request. currentParentHeader установлен: {msg_id: 'c06b037c-7f03eeb634ab6e033f8bb7d0_3367_13', msg_type: 'input_request', username: 'username', session: 'c06b037c-7f03eeb634ab6e033f8bb7d0', date: '2025-07-31T19:08:06.947924Z', …}
python-4.html:733 Отправлено сообщение input_reply: 7d9b49dd-74bc-4c0d-a551-ab6f64b74d61 для session (принудительно): 8ccfcfaa-fb1e-4690-a7ac-2a6e5a17ea9e

Environment:

• Jupyter Kernel Gateway Version: (Please specify your Kernel Gateway version, e.g., output of jupyter kernelgateway --version)
• Client: Custom HTML/JavaScript based IDE using WebSocket for Jupyter Protocol communication.
• Operating System: (e.g., Linux, Windows, macOS)
• Python Version: (e.g., Python 3.9)

Additional Context:

This issue makes interactive input (input()) unusable with Jupyter Kernel Gateway, as the kernel consistently gets stuck. The client-side code has been modified to attempt to force the header.session of the input_reply to match the client's kernelId, but this workaround is ineffective due to the server's internal session ID mismatch.

---

[vincentye38]

Based on the first note in https://jupyter-client.readthedocs.io/en/latest/messaging.html

The session ID in a message header identifies a unique entity with state, such as a kernel process or client process.
.......
A client session ID, in message headers from a client, should be unique among all clients connected to a kernel. 
......
A kernel session ID, in message headers from a kernel, should identify a particular kernel process.

The header.session in input_request is the kernel session id.
The header.session in execute_request and input_reply are the client session id.
The parent_header.session of input_request is client session id because it's pointing to execute_request.
The parent_header.session of input_reply is kernel session id because it's pointing to input_request.

Here are the messages for executing a cell with the following code:

import getpass 

getpass.getpass("Provide password:")

[vincentye38]

IMO, client can create its own session id (doesn't have to be the kernel id). And keep using it in header.session in the consecutive messages sent to kernel. The kernel will keep using its own session id for a given client session.
Kernel id is encoded in the URL used to establish the websocket, and client session id is set as session url parameter. The client session id in the url parameter is for the ZMQWebsocketConnection to buffer and replay messages for the client reconnecting back with the same session id.

[vincentye38]

shakhbanov:
I don't know if you connect your client directly to JKG, or through JupyterServer? If you use JupyterServer and configure it to use GatewayWebSocketConnection to connect to JKG, there is a bug (fixed by this PR) that causes the session id changed each time the client disconnecting and connecting back to the server. As a result, the buffered messages from Kernel in ZMQWebsocketConnection in JKG for the previous client session are dropped.