Summary

wts_open opens the operations connection without loading any early_load=true extensions. Any extension registered with early_load=true will be absent from the connection used by the operations loop.

Root Cause

create_database (called once at startup) builds its config string with an extensions=[...] block that includes all extension paths. That connection opens, runs its work, and closes.

wts_open (called next, to open the connection the operations loop actually uses) calls configure_disagg_storage, which fills a local disagg_ext_cfg buffer with the extension paths — but then never appends an extensions=[...] block to the config. So wiredtiger_open runs without listing any extensions.

Non-early_load extensions are unaffected because WT persists them in WiredTiger.basecfg and auto-reloads them on every subsequent open. early_load=true extensions are explicitly not auto-reloaded and must be re-listed in the open config every time.

Compounding Issue

wts_open's config buffer is char config[1024]. Once the extensions=[...] block is added (mirroring create_database), the assembled config string exceeds 1024 bytes for typical configurations, smashing the stack canary and aborting with __stack_chk_fail. The same buffer in create_database is char config[8 * 1024] — that detail was already present in the codebase but not applied to wts_open.

Fix

1. Append the same extensions=[...] block to wts_open's config that create_database already uses, with disagg_ext_cfg as the page-log entry.
2. Bump config[1024] to config[8 * 1024] to match create_database's sizing.