Description
When a context's setup procedure (e.g. procedures/<subkernel>/setup.py) raises a Python error while it is executed during context initialization, the whole context initialization aborts and the session is left in a broken, confusing state.
From the user's point of view:
- The notebook connects and initially looks healthy — there is no visible error and no indication that anything went wrong.
- No new code can be executed against the kernel.
- Attempting to talk to the agent throws an error.
The only sign of the real cause is in the server logs.
Cause (as observed)
The setup procedure is run inside the context's setup(), typically as await context.execute(context.get_code("setup", ...)). An exception there propagates out of BeakerContext.setup() → BeakerKernel.set_context() → the start_default_context task created in BeakerKernel.__init__ (src/beaker_notebook/kernel.py:88-91).
BeakerKernel.startup_error_callback (src/beaker_notebook/kernel.py:94) logs the exception and calls self.context.cleanup(), but nothing after the failure point runs: the subkernel setup hook, the connection-file update, the preview, and the kernel-state message are all skipped, and no error is reported to the front end. The kernel process stays alive, so the client sees a live connection attached to a context that was never finished.
Desired end state
- An error raised by a context setup procedure is caught rather than allowed to abort initialization.
- Context initialization continues to completion, so the kernel is usable: code can be executed and the agent can be reached.
- Once the context is initialized, a message is added in the notebook telling the user that the setup procedure failed, including enough detail (the error/traceback) to diagnose it.
Acceptance criteria
- With a context whose setup procedure raises, the notebook still initializes and can execute code and communicate with the agent.
- The setup failure is surfaced to the user in the notebook, not only in the server logs.
- A context whose setup procedure succeeds behaves exactly as before.
Description
When a context's
setupprocedure (e.g.procedures/<subkernel>/setup.py) raises a Python error while it is executed during context initialization, the whole context initialization aborts and the session is left in a broken, confusing state.From the user's point of view:
The only sign of the real cause is in the server logs.
Cause (as observed)
The setup procedure is run inside the context's
setup(), typically asawait context.execute(context.get_code("setup", ...)). An exception there propagates out ofBeakerContext.setup()→BeakerKernel.set_context()→ thestart_default_contexttask created inBeakerKernel.__init__(src/beaker_notebook/kernel.py:88-91).BeakerKernel.startup_error_callback(src/beaker_notebook/kernel.py:94) logs the exception and callsself.context.cleanup(), but nothing after the failure point runs: the subkernelsetuphook, the connection-file update, the preview, and the kernel-state message are all skipped, and no error is reported to the front end. The kernel process stays alive, so the client sees a live connection attached to a context that was never finished.Desired end state
Acceptance criteria