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
- If hit accidentally, simply stop using the `sync_crash_me` table function — it always panics by design.
- Ensure the message argument is a plain string if you need a recognizable panic message in tests.
- 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
- Never reference sync_crash_me outside of dedicated fault-injection tests.
- Restrict registration of test-only table functions to debug builds.
- When writing crash tests, assert on the panic message so unrelated panics are not masked.
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
- failed to infer billing_usage_daily schema
- Temp table id used up
- Invalid temp table desc
- expect tuple type
- invalid month
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)