Hmbown/CodeWhale · error
REPL kernel initialized above
Error message
REPL kernel initialized above
What it means
The REPL execution path expects self.repl_kernel to be Some because the kernel is initialized earlier in the round (with a failure path that breaks out of the turn on error). Hitting the expect means execution continued past kernel initialization without it — a control-flow bug in the turn loop.
Source
Thrown at crates/tui/src/core/engine/turn_loop.rs:1673
if self.repl_kernel.is_none() {
self.repl_kernel = match crate::repl::runtime::PythonRuntime::new().await {
Ok(runtime) => Some(runtime),
Err(e) => {
let _ = self
.tx_event
.send(Event::status(format!("REPL init failed: {e}")))
.await;
turn_error = Some(format!("REPL init failed: {e}"));
break;
}
};
}
let kernel_context = self.repl_kernel_context();
let refresh_result = self
.repl_kernel
.as_mut()
.expect("REPL kernel initialized above")
.replace_context(&kernel_context)
.await;
if let Err(e) = refresh_result {
// A broken subprocess cannot be trusted to retain
// state. Drop it so a later model step gets a clean,
// freshly bootstrapped kernel instead of repeating a
// hidden failure.
self.repl_kernel = None;
let _ = self
.tx_event
.send(Event::status(format!("REPL context refresh failed: {e}")))
.await;
turn_error = Some(format!("REPL context refresh failed: {e}"));
break;
}
// Child queries use the same object-safe client as the
// root turn. This follows the user-selected provider andView on GitHub (pinned to 0c42157ee5)
Solutions
- Ensure the early-return/break on REPL init failure covers every path that reaches execution
- Re-check the lazy-init condition guarding kernel creation
Defensive patterns
Strategy: type-guard
When it happens
Trigger: Thrown at crates/tui/src/core/engine/turn_loop.rs:1673 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20).
Data as JSON: /api/errors/d2c36bddc6e53a1c.
Report an issue: GitHub.