When Reedline may encounter "The cursor position could not be read within a normal duration"?
I wonder when Reedline may encounter the internal error "The cursor position could not be read within a normal duration".
I can't stably reproduce it but here is the structure of my code:
let mut state = Reedline::create()
.with_validator(Box::new(ScopeQLValidator))
.with_highlighter(Box::new(ScopeQLHighlighter));
loop {
let input = state
.read_line(&prompt)
.change_context_lazy(|| Error::Other("failed to read next line".to_string()))?;
let input = match input {
Signal::CtrlC | Signal::CtrlD => {
println!("exit");
break;
}
Signal::Success(input) => input,
};
let input = input.trim();
// other biz code
state.run_edit_commands(&[EditCommand::InsertString(
outstanding.trim_start().to_string(),
)]);
}
And today in Ubuntu Terminal I encounter:
thread 'main' panicked at cmd/scopeql/src/main.rs:50:78:
called `Result::unwrap()` on an `Err` value: failed to read next line
|- at cmd/scopeql/src/repl/entrypoint.rs:42:14
|
| -> The cursor position could not be read within a normal duration
| - at cmd/scopeql/src/repl/entrypoint.rs:42:14
I have no idea when this error may occur and find no way to investigate deeper.
That looks to be a crossterm error message. https://github.com/crossterm-rs/crossterm/blob/e104a7cb400910609cdde36f322e3905c4baa805/src/cursor/sys/unix.rs#L50
@fdncred Yeah.
Do you have some information here to investigate more? Anyway, it's hidden behind reedline's API. I don't know how the error variant can be hit here.
Not really. It looks to me like crossterm is asking the terminal for the cursor position, waits 2 seconds without a response and then times out with that error.
Well. I have no background how "asking for cursor position" can hang or fail :P
Me either. It may be worth asking on the crossterm repo. I just looks like if crossterm fails to get a lock for the event reader it would fail. I'm not sure what would cause that.