Conversation
|
Will this also work for api service clients like the IDE extension? Looks like it's TUI-only? |
| @@ -30,16 +30,14 @@ pub(crate) fn spawn_agent( | |||
| .. | |||
| } = match server.start_thread(config).await { | |||
There was a problem hiding this comment.
@etraut-openai to answer your question about "Will this also work for api service clients like the IDE extension?" I believe the crux of the issue is how the UI deals with an Err from start_thread().
I believe it is already doing the right thing here:
codex/codex-rs/app-server/src/codex_message_processor.rs
Lines 1333 to 1356 in 3c711f3
There was a problem hiding this comment.
I'm working on a new PR that surfaces config parsing errors correctly to app server clients. I'll extend it to handle malformed rules errors as well.
|
|
||
| /// Handle the app exit and print the results. Optionally run the update action. | ||
| fn handle_app_exit(exit_info: AppExitInfo) -> anyhow::Result<()> { | ||
| match exit_info.exit_reason { |
There was a problem hiding this comment.
It looks like this runs only in interactive mode. What about non-interactive mode (codex exec)? I think we'd want this same error printed in that case.
There was a problem hiding this comment.
This already appears to work as intended for codex exec:
$ ./codex-rs/target/debug/codex exec hi
Error: Fatal error: failed to load execpolicy: failed to read execpolicy files from /Users/mbolin/.codex/rules: Not a directory (os error 20)
| @@ -30,16 +30,14 @@ pub(crate) fn spawn_agent( | |||
| .. | |||
| } = match server.start_thread(config).await { | |||
There was a problem hiding this comment.
I'm working on a new PR that surfaces config parsing errors correctly to app server clients. I'll extend it to handle malformed rules errors as well.
codex-rs/tui/src/lib.rs
Outdated
| token_usage: codex_core::protocol::TokenUsage::default(), | ||
| thread_id: None, | ||
| update_action: Some(action), | ||
| fatal_error_message: ExitReason::UserRequested, |
There was a problem hiding this comment.
| fatal_error_message: ExitReason::UserRequested, | |
| exit_reason: ExitReason::UserRequested, |
There was a problem hiding this comment.
Good catch! Fixed and ran cargo build --bin codex --release locally to verify the fix.
joshka-oai
left a comment
There was a problem hiding this comment.
Approved - but make sure to fix #9011 (comment)
The underlying issue is that when we encountered an error starting a conversation (any sort of error, though making
$CODEX_HOME/rulesa file rather than folder was the example in #8803), then we were writing the message to stderr, but this could be printed over by our UI framework so the user would not see it. In general, we disallow the use ofeprintln!()in this part of the code for exactly this reason, though this was suppressed by an#[allow(clippy::print_stderr)].This attempts to clean things up by changing
handle_event()andhandle_tui_event()to return aResult<AppRunControl>instead of aResult<bool>, which is a new type introduced in this PR (and depends onExitReason, also a new type):This makes it possible to exit the primary control flow of the TUI with richer information. This PR adds
ExitReasonto the existingAppExitInfostruct and updateshandle_app_exit()to print the error and exit code1in the event ofExitReason::Fatal.I tried to create an integration test for this, but it was a bit involved, so I published it as a separate PR: #9166. For this PR, please have faith in my manual testing!
Fixes #8803.
Stack created with Sapling. Best reviewed with ReviewStack.