zellij-org/zellij · error · anyhow::Error
ScrollUpByPaneId missing pane_id
Error message
ScrollUpByPaneId missing pane_id
What it means
First of the pane-targeted scroll actions in the protobuf conversion: ScrollUpByPaneId scrolls one specific pane, so the `pane_id` field is mandatory. An incoming action with pane_id unset (Option::None in prost) fails conversion at this .ok_or_else() and no scrolling happens.
Source
Thrown at zellij-utils/src/ipc/protobuf_conversion.rs:2914
ActionType::ToggleGroupMarking(_) => {
Ok(crate::input::actions::Action::ToggleGroupMarking)
},
ActionType::SetPaneColor(set_pane_color_action) => {
Ok(crate::input::actions::Action::SetPaneColor {
pane_id: set_pane_color_action
.pane_id
.ok_or_else(|| anyhow!("SetPaneColor missing pane_id"))?
.try_into()?,
fg: set_pane_color_action.fg,
bg: set_pane_color_action.bg,
})
},
// Pane-targeting CLI-only variants
ActionType::ScrollUpByPaneId(a) => {
Ok(crate::input::actions::Action::ScrollUpByPaneId {
pane_id: a
.pane_id
.ok_or_else(|| anyhow!("ScrollUpByPaneId missing pane_id"))?
.try_into()?,
})
},
ActionType::ScrollDownByPaneId(a) => {
Ok(crate::input::actions::Action::ScrollDownByPaneId {
pane_id: a
.pane_id
.ok_or_else(|| anyhow!("ScrollDownByPaneId missing pane_id"))?
.try_into()?,
})
},
ActionType::ScrollToTopByPaneId(a) => {
Ok(crate::input::actions::Action::ScrollToTopByPaneId {
pane_id: a
.pane_id
.ok_or_else(|| anyhow!("ScrollToTopByPaneId missing pane_id"))?
.try_into()?,
})View on GitHub (pinned to 98a0837077)
Solutions
- Set pane_id to the pane that should scroll before sending
- Regenerate the client's protobuf stubs from the running server's schema
- Match client and server zellij versions
- Validate pane_id presence before sending; use the plain Scroll action if you mean the focused pane
Example fix
// before
ScrollUpAction::default() emitted as ScrollUpByPaneId // pane_id: None
// after
ScrollUpAction { pane_id: Some(target_pane_id as u64) } Defensive patterns
Strategy: validation
Validate before calling
if let ActionType::ScrollUpByPaneId(a) = action.action_type.as_ref().unwrap() {
if a.pane_id.is_none() {
anyhow::bail!("ScrollUpByPaneId requires pane_id");
}
} Type guard
fn scroll_up_by_pane_id_is_valid(a: &ScrollUpAction) -> bool {
a.pane_id.is_some()
} Try / catch
match protobuf_action.try_into() {
Ok(action) => dispatch(action),
Err(e) if e.to_string().contains("ScrollUpByPaneId missing pane_id") => {
log::warn!("dropping ScrollUpByPaneId without pane_id");
},
Err(e) => return Err(e.context("action conversion failed")),
} Prevention
- These ByPaneId actions exist to target arbitrary panes: the id is never optional in practice
- Fetch live pane ids at runtime rather than hardcoding them
- Prefer `zellij action scroll-up --pane-id N` from the CLI, which always sets the field
- Guard all pane-targeting actions with one shared pane_id-presence validator
When it happens
Trigger: IPC clients emitting ScrollUpByPaneId without pane_id — half-populated payloads, tooling that targets 'the focused pane' by omitting the id (not supported: these CLI-only variants exist precisely to target arbitrary panes), or stub drift.
Common situations: Automation scrolling output in background panes; clients built against an older proto; replayed action captures missing fields.
Related errors
- ScrollDownByPaneId missing pane_id
- ScrollToTopByPaneId missing pane_id
- ScrollToBottomByPaneId missing pane_id
- ChangeFloatingPaneCoordinates missing pane_id
- TogglePaneBorderless missing pane_id
AI-assisted analysis of zellij-org/zellij@98a0837077 (2026-08-16).
Data as JSON: /api/errors/80e1906821ae18d1.
Report an issue: GitHub.