From 038767af6928ca9bd0ecd99a914cd067daca9bdf Mon Sep 17 00:00:00 2001 From: Michael Bolin Date: Wed, 10 Dec 2025 16:51:33 -0800 Subject: [PATCH] fix: add a hopefully-temporary sleep to reduce test flakiness (#7848) Let's see if this `sleep()` call is good enough to fix the test flakiness we currently see in CI. It will take me some time to upstream a proper fix, and I would prefer not to disable this test in the interim. --- .../exec-server/tests/suite/accept_elicitation.rs | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/codex-rs/exec-server/tests/suite/accept_elicitation.rs b/codex-rs/exec-server/tests/suite/accept_elicitation.rs index 1858deeecb..a9c6978a0e 100644 --- a/codex-rs/exec-server/tests/suite/accept_elicitation.rs +++ b/codex-rs/exec-server/tests/suite/accept_elicitation.rs @@ -3,6 +3,7 @@ use std::borrow::Cow; use std::path::PathBuf; use std::sync::Arc; use std::sync::Mutex; +use std::time::Duration; use anyhow::Context; use anyhow::Result; @@ -82,6 +83,18 @@ prefix_rule( }; notify_readable_sandbox(&project_root_path, codex_linux_sandbox_exe, &service).await?; + // TODO(mbolin): Remove this hack to remove flakiness when possible. + // As noted in the commentary on https://github.com/openai/codex/pull/7832, + // an rmcp server does not process messages serially: it takes messages off + // the queue and immediately dispatches them to handlers, which may complete + // out of order. The proper fix is to replace our custom notification with a + // custom request where we wait for the response before proceeding. However, + // rmcp does not currently support custom requests, so as a temporary + // workaround we just wait a bit to increase the probability the server has + // processed the notification. Assuming we can upstream rmcp support for + // custom requests, we will remove this once the functionality is available. + tokio::time::sleep(Duration::from_secs(4)).await; + // Call the shell tool and verify that an elicitation was created and // auto-approved. let CallToolResult {