SIGTRAP crash in TestCluster_MultiNodeLifecycle on management node restart

[VGSML]

Description

TestCluster_MultiNodeLifecycle crashes with a SIGTRAP (signal arrived during cgo execution) during Step 7 — management node restart. The crash occurs inside native DuckDB code when re-applying catalogs to a previously persisted database file.

Steps to Reproduce

CGO_CFLAGS="-O1 -g" go test -tags=duckdb_arrow -v -run TestCluster_MultiNodeLifecycle ./integration-test/cluster/...

Environment

• Go 1.26, macOS (darwin/arm64)
• duckdb-go/v2 v2.10500.0
• duckdb-go-bindings v0.10500.0

Stack Trace

The crash happens at Step 7 (cluster_test.go:334) when createEngine is called a second time with the same DB file paths after mgmt.Close():

SIGTRAP: trace trap
signal arrived during cgo execution

goroutine 6 [syscall]:
runtime.cgocall(...)
github.com/duckdb/duckdb-go-bindings._Cfunc_duckdb_prepare_extracted_statement(...)
  bindings.go:1699
github.com/duckdb/duckdb-go/v2.(*Conn).prepareExtractedStmt(...)
  connection.go:206
github.com/duckdb/duckdb-go/v2.(*Conn).prepareStmts(...)
  connection.go:255
github.com/duckdb/duckdb-go/v2.(*Conn).ExecContext(...)
  connection.go:59
...
github.com/hugr-lab/query-engine/pkg/catalog/db.(*Provider).upsertField(...)
  write.go:359
github.com/hugr-lab/query-engine/pkg/catalog/db.(*Provider).processExtension(...)
  write.go:561
github.com/hugr-lab/query-engine/pkg/catalog/db.(*Provider).updateImpl(...)
  write.go:164
github.com/hugr-lab/query-engine/pkg/catalog/db.(*Provider).compileAndApply(...)
  catalog_manager.go:60
github.com/hugr-lab/query-engine/pkg/catalog/db.(*Provider).AddCatalog(...)
  catalog_manager.go:132
...
github.com/hugr-lab/query-engine.(*Service).attachRuntimeSources(...)
  data_sources.go:63
github.com/hugr-lab/query-engine.(*Service).Init(...)
  engine.go:238

Analysis

• The management node is correctly writing catalogs (only management writes, workers read).
• The crash occurs inside duckdb_prepare_extracted_statement — a native DuckDB C function — when preparing an SQL statement for upsertField during catalog re-application on restart.
• This suggests either a DuckDB storage corruption after Close() + reopen in the same process, or a state issue in the duckdb-go bindings when reusing a connector/database path.
• All other cluster tests pass (TestCluster_ManagementInit, TestCluster_NodeRegistration, TestCluster_ManagementURL, TestStandalone_NoClusterSideEffects, TestStandalone_LoadUnloadCycle).

Possible Causes

1. DuckDB internal state not fully cleaned up after Close() when reopening the same file in the same process
2. Bug in duckdb-go-bindings v0.10500.0 around prepared statement handling on persisted databases
3. Race condition in DuckDB WAL recovery during concurrent catalog writes on restart