Unexpected end of JSON input

[juntyr]

Description

I'm trying out the jupyterlite-terminal extension in a custom JupyterLite deployment, which disables the service worker but runs in a secure context (so the contents drive is available). When executing any command, it fails with a JSON parse error.

Reproduce

1. Go to https://lab.climet.eu/main/lab/index.html
2. Open a new terminal
3. Execute the ls command

Expected behavior

The terminal command should execute.

Context

• JupyterLite version: 0.4.2
• Operating System and version: MacBook
• Browser and version: Chrome or Firefox

Browser Output

JupyterLab extension @jupyterlite/terminal:plugin is activated!
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 terminals available: true
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 terminals ready: false
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 terminals active: true
index.js:185 JupyterLite ServiceWorker not available
o @ index.js:185
index.js:188 Kernel filesystem and JupyterLite contents will NOT be synced
o @ index.js:188
index.js:33 Memory storage fallback enabled: contents and settings may not be saved
activate @ index.js:33
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 terminals ready after await: true
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Terminals.constructor wss://lab.climet.eu/main/
610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 JupyterLab extension @jupyterlite/terminal:routes-plugin is activated! o
/main/git-pull/api?1730811538138:1 
   Failed to load resource: the server responded with a status of 404 ()

389.f067a180c43ff46da6db.js?v=f067a180c43ff46da6db:1 JupyterLab extension @jupyterlite/litegitpuller is activated!

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Terminals.new 1

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Terminal.wsConnect wss://lab.climet.eu/main/terminals/websocket/1

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Terminals.list Array(1)

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> server connection r Proxy(e)[[Handler]]: Object[[Target]]: e[[IsRevoked]]: false

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Returning handshake via socket ["setup"]

817.7297f5b6dcf0b0f72dec.js?v=7297f5b6dcf0b0f72dec:2 Importing JS/WASM from https://lab.climet.eu/main/extensions/@jupyterlite/terminal/static/wasm/fs.js

817.7297f5b6dcf0b0f72dec.js?v=7297f5b6dcf0b0f72dec:2 Importing JS/WASM from https://lab.climet.eu/main/extensions/@jupyterlite/terminal/static/wasm/coreutils.js

610.c0ae8fe065dc81c2a812.js?v=c0ae8fe065dc81c2a812:1 ==> Terminals.list Array(1)

[ianthomas23]

I can reproduce just by disabling the service worker, although that gives me a different error:

js-shell: ls
ErrnoError: Invalid argument

Evidently the service worker is currently required.

[juntyr]

JupyterLite itself is able to use shared array buffers (when CORS isolated) instead of the service worker. This allows me to use the contents drive even without the service worker. Would it be possible that the terminal can also use either alternative?

[juntyr]

Here is where the Pyodide kernel switches between the comlink (service worker based) and coincident (shared array buffer based) worker: https://github.com/jupyterlite/pyodide-kernel/blob/6a2777961fcefb7ff4f0a907aad4726aea2f7e23/packages/pyodide-kernel/src/kernel.ts#L46

[ianthomas23]

cockle, the project that implements the shell functionally used here, currently requires shared array buffer to work and hence this terminal extension does too. The service worker requirement must be due to the use of DriveFS that connects cockle to the JupyterLite filesystem, whether that is an explicit or implicit dependency.

Future changes in this and indeed in everything else in both cockle and terminal are likely as we try to solve some of the big issues that are required for this to be a viable project long-term. That's the priority, everything else will have to wait but may accidentally be solved by some of those big changes.

[juntyr]

The lower prioritisation right now makes sense :)

As far as I understand, DriveFS by default uses the service worker, but can be subclassed to use shared array buffers, which is what the pyodide-kernel uses. So in theory all needed code should already be there.