Hmbown/CodeWhale · error · anyhow::Error
another terminal clipboard write is still queued
Error message
another terminal clipboard write is still queued
What it means
Back-pressure error from enqueue: the terminal clipboard writer's bounded mpsc request channel is already holding an unwritten clipboard write, so try_send returns TrySendError::Full and this write is rejected rather than silently dropped or blocking the TUI thread.
Source
Thrown at crates/tui/src/tui/clipboard.rs:246
break;
}
}
})
.context("spawn terminal clipboard writer")?;
Ok(Self {
request_tx,
completion_rx,
})
}
fn enqueue(&self, text: &str, in_tmux: bool) -> Result<()> {
let request = TerminalClipboardWriteRequest {
text: text.to_string(),
in_tmux,
};
self.request_tx.try_send(request).map_err(|err| match err {
std::sync::mpsc::TrySendError::Full(_) => {
anyhow::anyhow!("another terminal clipboard write is still queued")
}
std::sync::mpsc::TrySendError::Disconnected(_) => {
anyhow::anyhow!("terminal clipboard writer stopped")
}
})
}
fn poll_completion(&self) -> Option<TerminalClipboardWriteCompletion> {
self.completion_rx.try_recv().ok()
}
}
/// Clipboard reader/writer helper.
pub struct ClipboardHandler {
terminal_context: TerminalClipboardContext,
terminal_writer: Option<TerminalClipboardWriter>,
#[cfg(any(
target_os = "macos",View on GitHub (pinned to 0c42157ee5)
Solutions
- Wait for the previously queued clipboard write to complete (completion_rx) before enqueueing again.
- Retry the clipboard write after a short delay; the queued write should drain quickly.
- Use an OS-level clipboard fallback (e.g. OSC52 or a clipboard crate) if terminal writes must never be coalesced.
Defensive patterns
Strategy: retry
When it happens
Trigger: Thrown at crates/tui/src/tui/clipboard.rs:246 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/22f65da55f6aac11.
Report an issue: GitHub.