Stale discovery / metadata
Why tables you deleted at the storage layer still show up - and how to avoid it.
A table you removed still appears in Eddytor, or a table that's there isn't listed. This is stale discovery: Eddytor's view of the bucket is out of sync with the bucket's actual contents.
The usual cause
Deleting (or adding) objects behind Eddytor's back - with an S3 client, the cloud console, or another tool - leaves Eddytor's discovery/metadata stale until the next discovery pass.
Heads up
Prefer in-Eddytor operations, which keep storage and
metadata consistent:
eddytor delete table eddytor <schema> <table> /
drop_table removes the Delta files and
deregisters the table in one step. Only touch the
S3 layer for orphaned data Eddytor no longer
tracks.Re-sync discovery
If the bucket did change out-of-band, re-run discovery to reconcile:
- Re-run discovery on the connection -
update_storage_config(config_id, …)re-scans (flipdiscover_files/ adjustbase_pathto pick up more). See How registration works. - Confirm the live state -
eddytor get tables/list_tablesafter the pass.
After a rename/move
Rename and move change a
table's path/FQN - calls using the old path will look "missing". Refresh the FQN
from list_tables before continuing; the table kept its
stable UUID.