b/241134681 's short term fix #2222 uses polling to fix the table_not_found issue.
As a long term cleaner solution & redesign we can explore:

1. Providing an API Future based async implementation which can offer more control to the users (in terms of cancelling the operation and checking the status)
2. Removing patch of logic related with queryDryRun which wont be necessary after this fix
3. See if we can optimise the fast and slow query paths. The current flow is a bit convoluted . Refactor the overloaded executeSelect methods to avoid code duplicity.
4. A similar error can probably occur in the fast query path if we get an incomplete job id from the backend and Read API is initialised on the basis of the response from useReadAPI
5. Exploring a JDBCish overloaded method [if we redesign executeSelect to return APIFuture, then we may want to have a synchronous counterpart like executeQuery as well to comply with JDBC standards]
6. Add user configurable timeout for getQueryResults RPC (it can be in the range 1 - 200 secs . Ref https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/getQueryResults)