Summary
drop_attribute removes the attribute from the schema and drops its data, but the entry in Table.indices is never removed. The map keeps the attribute's key, and with it the store handle for an index that no longer has an attribute behind it.
Confirmed by source read
Nothing in the repository ever deletes an entry from that map:
$ grep -rn "delete .*\.indices\[" --include='*.ts' --include='*.js' .
(no matches)
dropAttribute (dataLayer/schema.ts:242) calls harperBridge.dropAttribute() and then dropAttributeFromGlobal(), which clears the global schema. Neither touches Table.indices. Every read site — resources/databases.ts:1774, :2210, :2230, :2267 — continues to see the entry, and the close loop at :1307 will still walk it.
So the state is not merely a leaked reference: the map is the live lookup for index dbis, and it now contains one for an attribute the schema says doesn't exist.
Reproduction context
Reproduced under a measured 4-way worker spread (dispatch task qa-wave-2026072509), which matters because the original observation assumed the worker spread rather than measuring it. That makes this an evidenced precondition rather than an assumed one.
Open questions
- Whether the retained dbi is only a leak (memory plus an open store handle per dropped attribute) or can also serve reads — i.e. whether a query naming the dropped attribute can still hit the stale index.
- Whether re-adding an attribute of the same name reuses the stale entry, and what happens to its contents if it does.
Both are worth answering before choosing the fix, since "delete the key on drop" and "make the map authoritative against the schema" are different-sized changes.
Related
Originally filed as a raw dispatch finding covering two separate findings; split during backlog triage so each carries its own evidence. This issue is F-193.
Summary
drop_attributeremoves the attribute from the schema and drops its data, but the entry inTable.indicesis never removed. The map keeps the attribute's key, and with it the store handle for an index that no longer has an attribute behind it.Confirmed by source read
Nothing in the repository ever deletes an entry from that map:
dropAttribute(dataLayer/schema.ts:242) callsharperBridge.dropAttribute()and thendropAttributeFromGlobal(), which clears the global schema. Neither touchesTable.indices. Every read site —resources/databases.ts:1774,:2210,:2230,:2267— continues to see the entry, and the close loop at:1307will still walk it.So the state is not merely a leaked reference: the map is the live lookup for index dbis, and it now contains one for an attribute the schema says doesn't exist.
Reproduction context
Reproduced under a measured 4-way worker spread (dispatch task
qa-wave-2026072509), which matters because the original observation assumed the worker spread rather than measuring it. That makes this an evidenced precondition rather than an assumed one.Open questions
Both are worth answering before choosing the fix, since "delete the key on drop" and "make the map authoritative against the schema" are different-sized changes.
Related
Originally filed as a raw dispatch finding covering two separate findings; split during backlog triage so each carries its own evidence. This issue is F-193.