Issue Summary

There is a bug in WiredTiger's statistics cursor logic where the file existence check passes for a .wt file inferred from a table URI, even though the file should not exist in disaggregated storage. This appears to be due to the way the fast path constructs the file name and checks for its existence, potentially leading to incorrect behavior when gathering table size statistics.

Context

• Logs show expected files: `collection-cd5191a4-995d-483f-8a57-53676b3982ae.wt` and `collection-7b8b176e-82a8-492c-8916-53734854898f.wt`.
• WiredTiger logs include:

  {"t":{"$date":"2026-04-23T19:03:57.878+00:00"},"s":"D2", "c":"WT", "id":22428, "ctx":"Disagg-0","msg":"WiredTigerUtil::checkApplicationMetadataFormatVersion  uri: {uri} ok range {minimumVersion} -> {maximumVersion} current: {version}","attr":{"uri":"table:collection-7b8b176e-82a8-492c-8916-53734854898f","minimumVersion":1,"maximumVersion":1,"version":1}}
  

• The statistics cursor constructs the file name from the table URI:

  WT_ERR(__wt_buf_fmt(session, &namebuf, "%s.wt", uri + strlen("table:")));
  

• The existence check passes unexpectedly:

  WT_ERR(__wt_fs_exist(session, namebuf.data, &exist));
  

• If `__wt_fs_exist` returns `ENOENT`, the error is bubbled up instead of taking the slow path, as seen in:

  if (F_ISSET(cst, WT_STAT_TYPE_SIZE)) {
      WT_RET(__curstat_size_only(session, uri, &was_fast, cst));
      if (was_fast)
          return (0);
  }
  

• There is suspicion that MongoDB's table creation path (`_create_table` -> `_schema_colgroup_source`) may be involved in creating these .wt files.

What needs to be done

• Review the table creation logic to confirm whether .wt files are being created incorrectly in disaggregated storage.

Original Slack thread: Slack Thread
This ticket was generated by AI from a Slack thread.