databendlabs/databend · warning

{}

Error message

{}

What it means

This is not a real failure but a deliberate testing hook: the `sync_crash_me` table function panics with a caller-supplied message (or a fixed message if none was given) when its `generate` method is invoked. It exists so tests can verify that the query engine survives a panic inside a table function source without corrupting the session.

Solutions

  1. If hit accidentally, simply stop using the `sync_crash_me` table function — it always panics by design.
  2. Ensure the message argument is a plain string if you need a recognizable panic message in tests.
  3. For production, guard the table function behind test-only builds/feature flags so it cannot be registered.

Example fix

// before: table function registered unconditionally
register_table_function(SyncCrashMeTable::create);
// after: register only in debug/test builds
#[cfg(any(debug_assertions, test))]
register_table_function(SyncCrashMeTable::create);
Defensive patterns

Strategy: try-catch

Validate before calling

// Before invoking, check the table function is the test hook
if table_function_name == "sync_crash_me" {
    // do not run in production paths
    return Err("sync_crash_me is a fault-injection test function");
}

Type guard

fn is_crash_me_function(name: &str) -> bool { name == "sync_crash_me" }

Try / catch

// The panic propagates as a task failure in the async executor; catch at the pipeline boundary
match pipeline_result {
    Err(err) if err.message().contains("sync crash me") => {
        log::warn!("expected fault injection: {}", err);
        // treat as expected failure in tests
    }
    other => other?,
}

Prevention

When it happens

Trigger: Executing the `sync_crash_me` table function (e.g. `SELECT * FROM sync_crash_me('my message')`); the panic fires on the first `generate()` call with the user-provided message string.

Common situations: Developers running crash-recovery or fault-injection tests, verifying panic propagation across the async executor boundary, or accidentally invoking the test table function in a production-like environment.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of databendlabs/databend@288d84d76e (2026-09-11). Data as JSON: /api/errors/83546ed5b1f40814. Report an issue: GitHub.

Appendix: source

Thrown at src/query/service/src/table_functions/sync_crash_me.rs:159

}

impl SyncCrashMeSource {
    pub fn create(
        scan: Arc<Progress>,
        output: Arc<OutputPort>,
        message: Option<String>,
    ) -> Result<ProcessorPtr> {
        SyncSourcer::create(scan, output, SyncCrashMeSource { message })
    }
}

impl SyncSource for SyncCrashMeSource {
    const NAME: &'static str = "sync_crash_me";

    fn generate(&mut self) -> Result<Option<DataBlock>> {
        match &self.message {
            None => panic!("sync crash me panic"),
            Some(message) => panic!("{}", message),
        }
    }
}

impl TableFunction for SyncCrashMeTable {
    fn function_name(&self) -> &str {
        self.name()
    }

    fn as_table<'a>(self: Arc<Self>) -> Arc<dyn Table + 'a>
    where Self: 'a {
        self
    }
}

View on GitHub (pinned to 288d84d76e)