Description
In logservice/eventstore/event_store.go, dispatcherMeta.tableStats is indexed only by TableID:
- declaration:
tableStats map[int64]subscriptionStats
- lookup:
e.dispatcherMeta.tableStats[dispatcherSpan.TableID]
- insertion:
e.dispatcherMeta.tableStats[dispatcherSpan.TableID][subStat.subID] = subStat
This assumes TableID is globally unique. However, that assumption does not hold across keyspaces: different keyspaces may have the same TableID.
As a result, subscriptions from different keyspaces can be placed into the same tableStats bucket.
Current behavior
This does not appear to cause an incorrect match in the current code path, because the later span checks compare StartKey and EndKey, and those keys already include the keyspace prefix. The exact-match path also uses TableSpan.Equal, which checks KeyspaceID explicitly.
So this looks like a hidden pit / fragile invariant rather than an immediately reproducible bug.
Why this is risky
The current implementation relies on an implicit rule: tableStats is keyed only by TableID, but correctness depends on all later matching logic remembering to compare the full span boundaries that carry keyspace information.
That makes the code easy to misuse in future refactors or new call paths, because the map key itself does not represent the full identity of a subscription span.
Suggested improvement
Make tableStats keyspace-aware, for example by using a composite key such as (KeyspaceID, TableID), or by using another comparable span identity that includes keyspace.
It would also help to add a unit test that registers the same TableID under different keyspaces and verifies they are not treated as candidates from the same logical bucket.
Description
In
logservice/eventstore/event_store.go,dispatcherMeta.tableStatsis indexed only byTableID:tableStats map[int64]subscriptionStatse.dispatcherMeta.tableStats[dispatcherSpan.TableID]e.dispatcherMeta.tableStats[dispatcherSpan.TableID][subStat.subID] = subStatThis assumes
TableIDis globally unique. However, that assumption does not hold across keyspaces: different keyspaces may have the sameTableID.As a result, subscriptions from different keyspaces can be placed into the same
tableStatsbucket.Current behavior
This does not appear to cause an incorrect match in the current code path, because the later span checks compare
StartKeyandEndKey, and those keys already include the keyspace prefix. The exact-match path also usesTableSpan.Equal, which checksKeyspaceIDexplicitly.So this looks like a hidden pit / fragile invariant rather than an immediately reproducible bug.
Why this is risky
The current implementation relies on an implicit rule:
tableStatsis keyed only byTableID, but correctness depends on all later matching logic remembering to compare the full span boundaries that carry keyspace information.That makes the code easy to misuse in future refactors or new call paths, because the map key itself does not represent the full identity of a subscription span.
Suggested improvement
Make
tableStatskeyspace-aware, for example by using a composite key such as(KeyspaceID, TableID), or by using another comparable span identity that includes keyspace.It would also help to add a unit test that registers the same
TableIDunder different keyspaces and verifies they are not treated as candidates from the same logical bucket.