Symptom

TSan reports a data race when two threads call WT_CONNECTION methods at the same time. It happens on the first run of test/csuite/schema_disagg_abort/smoke.sh (-r l -t 10 -T 2) in the node process, on both TSan variants: 7 warnings on ubuntu2004-tsan and 8 on amazon2023-arm64-tsan. Found in WT-18737 validation patch 549 (6ab4ddcf3579730007f34a00).

WARNING: ThreadSanitizer: data race
  Write of size 8 at 0x7f632431c160 by thread T23:
    #0 __conn_query_timestamp src/conn/conn_api.c:1414:5
    #1 query_ts test/csuite/schema_disagg_abort/main.c:77:5
    #2 ckpt_take_periodic test/csuite/schema_disagg_abort/ckpt.c:231:32
  Previous write of size 8 at 0x7f632431c160 by thread T20:
    #0 __conn_set_timestamp src/conn/conn_api.c:1442:5
    #1 set_ts test/csuite/schema_disagg_abort/main.c:103:5
    #2 thread_ts_run test/csuite/schema_disagg_abort/ckpt.c:188:17
  Location is heap block of size 405960 allocated by main thread:
    #2 __wti_connection_open src/conn/conn_open.c:25:5
SUMMARY: ThreadSanitizer: data race src/conn/conn_api.c:1414:5 in __conn_query_timestamp

The other warnings are at conn_api.c:1420 (API_END_RET) and session_inline.h:54/:69 (__wt_single_thread_check_start/_stop).

Cause

CONNECTION_API_CALL runs every WT_CONNECTION method on conn->default_session (api.h:221-223). That is the dummy_session embedded in the connection (connection.h:933-934), so every thread calling a connection method shares one session. The API entry and exit do unsynchronized writes to it:

• ++api_call_counter, and plain stores of dhandle and lastop (API_SESSION_PUSH, api.h:11-20).
• cache_wait_us, and the api_call_counter == 1 error-reset and op-timer paths (api.h:41-49).
• thread_check.entry_count. The single-thread check skips its lock for the default session but still increments and decrements the count (session_inline.h:54, :69).

Inference, not observed: a lost update to api_call_counter could skip the error reset or op timer, or trip the reentry assert in API_SESSION_PUSH in diagnostic builds.

WT-13640 fixed a similar sharing problem for the default session's scratch buffers.

Reproduce

Build with TSan and run bash ./smoke.sh from build/test/csuite/schema_disagg_abort. The race is between the test's timestamp thread (conn->set_timestamp) and its checkpoint thread (conn->query_timestamp).

Impact

The TSan smoke for schema_disagg_abort can't run until this is fixed. WT-18737 leaves it commented out on ubuntu2004-tsan and amazon2023-arm64-tsan under a FIXME pointing at this ticket.