Describe the bug
When multiple ExtendDB instances share the same MongoDB catalog, the per-instance cache can retain a negative “no indexes” result after another instancecreates a
Global Secondary Index.
The stale negative result remains valid until the local cache time-to-live expires. During that window, writes handled by the second instance may take theno-index
fast path and skip index maintenance.
To Reproduce
- Start two ExtendDB instances connected to the same MongoDB replica set and catalog.
- Use instance B to access a table without secondary indexes, populating its local “no indexes” cache entry.
- Use instance A to add a Global Secondary Index to that table with
UpdateTable.
- Before instance B’s cache entry expires, write an item through instance B.
- Query the new index and inspect its indexed documents.
Expected behavior
All instances should recognize the new index before using the no-index fast path, or otherwise ensure that writes during the cache window are correctly indexed.
Actual behavior
Instance B may continue using its stale negative cache entry and perform a write without maintaining the newly created index. The item may therefore be absentfrom
the index until another reconciliation or backfill operation corrects it.
Environment
- ExtendDB version:
- Operating system:
- MongoDB version: 7.0+
- Rust version (if building from source):
- Client SDK/driver and version:
- Deployment method: source
- Number of ExtendDB instances: 2
Logs / stack trace
No error is necessarily reported. This is a race-dependent consistency issue.
Additional context
This is a follow-up to the MongoDB index-cache race fixes. The current cache invalidation is local to each ExtendDB process, so an invalidation on one instancedoes
not immediately invalidate the corresponding negative cache entry on another instance.
Possible solutions include reducing the negative-cache time-to-live, adding shared or cross-instance invalidation, or ensuring that writes during the window are
conservatively routed through index-aware handling.
Checklist
Describe the bug
When multiple ExtendDB instances share the same MongoDB catalog, the per-instance cache can retain a negative “no indexes” result after another instancecreates a
Global Secondary Index.
The stale negative result remains valid until the local cache time-to-live expires. During that window, writes handled by the second instance may take theno-index
fast path and skip index maintenance.
To Reproduce
UpdateTable.Expected behavior
All instances should recognize the new index before using the no-index fast path, or otherwise ensure that writes during the cache window are correctly indexed.
Actual behavior
Instance B may continue using its stale negative cache entry and perform a write without maintaining the newly created index. The item may therefore be absentfrom
the index until another reconciliation or backfill operation corrects it.
Environment
Logs / stack trace
No error is necessarily reported. This is a race-dependent consistency issue.
Additional context
This is a follow-up to the MongoDB index-cache race fixes. The current cache invalidation is local to each ExtendDB process, so an invalidation on one instancedoes
not immediately invalidate the corresponding negative cache entry on another instance.
Possible solutions include reducing the negative-cache time-to-live, adding shared or cross-instance invalidation, or ensuring that writes during the window are
conservatively routed through index-aware handling.
Checklist