Where: astrodb_utils.sources.find_source_in_db (reached via ingest_source(..., search_db=True)).
What happened: Ingesting the very first source into a brand-new, completely empty Sources table with search_db=True failed on every single row with "None of [Index(['ra_deg', 'dec_deg'], dtype='str')] are in the [columns]". This comes from find_source_in_db's coordinate-based db.query_region(...) fallback (reached because there's no name match yet), which appears to return a DataFrame with no columns at all when queried against a table with zero rows, so the subsequent db_name_matches[ra_col_name] access fails with a KeyError-style pandas error.
Workaround (downstream, in a skill): Set search_db=False for the first bulk ingest into a fresh table, since there's nothing to dedupe against yet. This isn't viable for any future incremental ingest into an already-populated table that still happens to hit this same zero-row-result path.
Suggested change: Guard the empty-table/empty-result case in find_source_in_db before indexing into db_name_matches[ra_col_name] — if db.query_region(...) returns zero rows (or a columnless DataFrame), treat it as "no spatial matches" and return/continue rather than raising a KeyError-shaped exception.
Cross-filed: Also filed against the astrodb-bot skills repo as astrodbtoolkit/astrodb-bot#101, which documents the same gotcha from the skill-user workaround side; this issue is for the actual astrodb_utils fix.
Reported from a gotchas.md log filed by a skill user (2026-08-28).
Where:
astrodb_utils.sources.find_source_in_db(reached viaingest_source(..., search_db=True)).What happened: Ingesting the very first source into a brand-new, completely empty
Sourcestable withsearch_db=Truefailed on every single row with"None of [Index(['ra_deg', 'dec_deg'], dtype='str')] are in the [columns]". This comes fromfind_source_in_db's coordinate-baseddb.query_region(...)fallback (reached because there's no name match yet), which appears to return a DataFrame with no columns at all when queried against a table with zero rows, so the subsequentdb_name_matches[ra_col_name]access fails with aKeyError-style pandas error.Workaround (downstream, in a skill): Set
search_db=Falsefor the first bulk ingest into a fresh table, since there's nothing to dedupe against yet. This isn't viable for any future incremental ingest into an already-populated table that still happens to hit this same zero-row-result path.Suggested change: Guard the empty-table/empty-result case in
find_source_in_dbbefore indexing intodb_name_matches[ra_col_name]— ifdb.query_region(...)returns zero rows (or a columnless DataFrame), treat it as "no spatial matches" and return/continue rather than raising a KeyError-shaped exception.Cross-filed: Also filed against the astrodb-bot skills repo as astrodbtoolkit/astrodb-bot#101, which documents the same gotcha from the skill-user workaround side; this issue is for the actual
astrodb_utilsfix.Reported from a gotchas.md log filed by a skill user (2026-08-28).