Skip to content

fix: skip missing DB tables gracefully instead of returning 500 - #343

Open
vmuralictr wants to merge 2 commits into
openmainframeproject:masterfrom
vmuralictr:fix/backend-graceful-missing-tables
Open

vmuralictr wants to merge 2 commits into
openmainframeproject:masterfrom
vmuralictr:fix/backend-graceful-missing-tables

Conversation

@vmuralictr

Copy link
Copy Markdown
Collaborator

Summary

The /searchPackages endpoint returned a 500 Internal Server Error when
a distro table was configured in distros.json but not yet created in the
database (e.g. a newly added distro whose data hasn't been loaded yet).

Root cause: The UNION ALL query included all configured table names without
checking if they exist, causing MySQL to throw a table-not-found error.

Fix: Added getExistingTables() which queries information_schema.TABLES
to filter the table list to only those that exist before building the query.
Missing tables are silently skipped — search still returns results from all
other distros.

Impact

  • "All" distro search no longer crashes when any table is missing
  • Backwards compatible — no config or schema changes needed
  • Makes the backend resilient during new distro onboarding

Testing

  • Verified search returns results with full bit flag (all distros selected)
  • Existing tests pass

@pleia2

pleia2 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

This is a good start, I've also encountered this issue.

However, before this change, a 500 error was an effective, if heavy-handed, way of notifying the person running the site that there was a problem with a missing source 😄

By implementing only this change, it fails silently on a missing table and continues running. This results in the "distro" being listed in the UI, but never returning any results. This could lead users to believe no results exist for that source, when it's just a misconfiguration that has gone unnoticed.

I think we have a few options here, and my inclination is one that also informs the user there is a problem via the UI. That would be easy for the administrator to spot, but also valuable to the user if something has gone wrong without the administrator noticing. Maybe some way for the backend to flag differences between the config and the tables, and have the react-frontend read that and present a warning?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants