zellij-org/zellij · error · anyhow::Error
Missing pixel_dimensions
Error message
Missing pixel_dimensions
What it means
Thrown while converting a ClientToServerMsg::TerminalPixelDimensions frame (zellij-utils/src/ipc/protobuf_conversion.rs): the outer message was present but its nested pixel_dimensions field (the PixelDimensions message with height/width/character_cell_size) was None. Optional message-typed fields do not get proto3 defaults, so an unset nested message is indistinguishable from an absent one and conversion refuses to invent values.
Source
Thrown at zellij-utils/src/ipc/protobuf_conversion.rs:211
}
}
// Convert protobuf ClientToServerMsg to Rust
impl TryFrom<ProtoClientToServerMsg> for ClientToServerMsg {
type Error = anyhow::Error;
fn try_from(msg: ProtoClientToServerMsg) -> Result<Self> {
match msg.message {
Some(client_to_server_msg::Message::DetachSession(detach)) => {
Ok(ClientToServerMsg::DetachSession {
client_ids: detach.client_ids.into_iter().map(|id| id as u16).collect(),
})
},
Some(client_to_server_msg::Message::TerminalPixelDimensions(pixel_dims)) => {
Ok(ClientToServerMsg::TerminalPixelDimensions {
pixel_dimensions: pixel_dims
.pixel_dimensions
.ok_or_else(|| anyhow!("Missing pixel_dimensions"))?
.try_into()?,
})
},
Some(client_to_server_msg::Message::BackgroundColor(bg_color)) => {
Ok(ClientToServerMsg::BackgroundColor {
color: bg_color.color,
})
},
Some(client_to_server_msg::Message::ForegroundColor(fg_color)) => {
Ok(ClientToServerMsg::ForegroundColor {
color: fg_color.color,
})
},
Some(client_to_server_msg::Message::ColorRegisters(color_regs)) => {
Ok(ClientToServerMsg::ColorRegisters {
color_registers: color_regs
.color_registers
.into_iter()View on GitHub (pinned to e839bfffa5)
Solutions
- Always populate pixel_dimensions (with character_cell_size where known) when sending the TerminalPixelDimensions variant.
- Update the zellij client on the sending side to a release matching the server.
- On the receiving side, treat a missing nested field as a protocol violation: skip/log the frame rather than propagating the error.
Example fix
// before
let msg = client_to_server_msg::Message::TerminalPixelDimensions(TerminalPixelDimensions::default());
// after: set the nested message
let msg = client_to_server_msg::Message::TerminalPixelDimensions(TerminalPixelDimensions {
pixel_dimensions: Some(PixelDimensions { height: Some(1080), width: Some(1920), character_cell_size: Some(SizeInPixels { width: 9, height: 18 }) }),
}); Defensive patterns
Strategy: validation
Validate before calling
// receiver side: skip frames that lack the nested message
let Some(pixel_dimensions) = pixel_dims.pixel_dimensions else {
log::warn!("TerminalPixelDimensions without pixel_dimensions; ignored");
return Ok(None);
}; Type guard
fn has_pixel_dimensions(m: &TerminalPixelDimensions) -> bool {
m.pixel_dimensions.is_some()
} Try / catch
match ClientToServerMsg::try_from(proto_msg) {
Ok(msg) => Some(msg),
Err(e) if e.to_string().contains("Missing pixel_dimensions") => {
log::warn!("peer sent pixel-dims frame without payload; frame ignored");
None
},
Err(e) => return Err(e),
} Prevention
- When constructing the TerminalPixelDimensions variant, always set pixel_dimensions in the same expression.
- Match zellij client/server versions so both sides agree the nested field is required.
- Centralize proto construction in one helper so no call site can omit the nested message.
When it happens
Trigger: A client sends the TerminalPixelDimensions variant without setting the nested pixel_dimensions message — older zellij client that predates the field, custom/web clients constructing the oneof member with defaults, or a test fixture omission.
Common situations: Version-mixed sessions (old client, new server); first implementations of custom clients copying the message shape incompletely; refactors that drop the nested assignment.
Related errors
- Missing new_size
- Invalid BareKey value: {}
- Invalid KeyModifier value: {}
- Character key needs character data
- Unspecified bare key
AI-assisted analysis of zellij-org/zellij@e839bfffa5 (2026-08-19).
Data as JSON: /api/errors/0e235fb8177212c0.
Report an issue: GitHub.