risingwavelabs/risingwave · error · Error

Wait for signal timeout

Error message

Wait for signal {0} timeout

What it means

sync-point's `Error::WaitTimeout` is returned when `wait_for_signal(name, timeout)` does not observe the registered sync-point signal within the given Duration. Sync points are test/diagnostic hooks: test code registers an action for a named point and waits for production code to hit it; a timeout means the code path never executed.

Solutions

  1. Register the sync-point action and start waiting BEFORE triggering the operation that hits the sync point.
  2. Verify the sync-point name string matches exactly the name used at the hit site.
  3. Increase the timeout or confirm the code path is actually reachable (check RW_SYNC_POINT configuration / feature gating).
  4. Check for deadlocks/upstream failures that prevent the sync point from ever executing.

Example fix

// before: race — operation may finish before wait starts
let handle = tokio::spawn(do_work());
sync_point::wait_for_signal("before-barrier", Duration::from_secs(1)).await?;
// after: wait first, then trigger
sync_point::set_action("before-barrier", action);
let handle = tokio::spawn(do_work());
sync_point::wait_for_signal("before-barrier", Duration::from_secs(30)).await?;
Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure sync-point is enabled and the name matches before waiting
assert!(std::env::var("RW_SYNC_POINT").is_ok(), "sync-point not configured");
// Register the action before triggering the code path
sync_point::set_action("before-barrier", action);

Try / catch

match sync_point::wait_for_signal("before-barrier", Duration::from_secs(30)).await {
    Ok(()) => {},
    Err(sync_point::Error::WaitTimeout(name)) => {
        eprintln!("sync point {name} never fired; check registration order and name");
    }
}

Prevention

When it happens

Trigger: Calling wait_for_signal with a timeout while the code under test never invokes the matching sync point (feature path not taken, env-gated sync-point disabled via RW_SYNC_POINT env, the operation completed before the wait started, or the wait timed out because the system is slow).

Common situations: Integration tests (e.g. barrier/pause tests in madsim or slow CI runners) that assume a code path fires; tests racing where the event happens before wait_for_signal starts; typos in the sync-point name string.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/53a520ecf769d707. Report an issue: GitHub.

Appendix: source

Thrown at src/utils/sync-point/src/lib.rs:24

//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

use std::collections::HashMap;
use std::future::Future;
use std::sync::Arc;
use std::time::Duration;

use futures_util::future::{BoxFuture, FutureExt};

#[derive(thiserror::Error, Debug)]
pub enum Error {
    #[error("Wait for signal {0} timeout")]
    WaitTimeout(&'static str),
}

pub type SyncPoint = &'static str;
type Action = Arc<dyn Fn() -> BoxFuture<'static, ()> + Send + Sync>;

static SYNC_FACILITY: spin::Once<SyncFacility> = spin::Once::new();

struct SyncFacility {
    /// `Notify` for each sync point.
    notifies: spin::Mutex<HashMap<SyncPoint, Arc<tokio::sync::Notify>>>,
    /// Actions for each sync point.
    actions: spin::Mutex<HashMap<SyncPoint, Action>>,
}

impl SyncFacility {
    fn new() -> Self {
        Self {

View on GitHub (pinned to 6469eb736d)