Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] The query history UI should use externalUrl instead of backendUrl #81

Open
lambrospetrou opened this issue Oct 27, 2023 · 1 comment

Comments

@lambrospetrou
Copy link

lambrospetrou commented Oct 27, 2023

Hello folks, we hit a bug using the new trino-gateway when opening query details from the gateway's UI displaying query history.

The trino-gateway uses backendUrl instead of externalUrl in the links it shows in the UI (see code) which means when opened from our internal users, they do not resolve properly since it's trying to use the internal endpoints that the gateway uses to communicate with the clusters.

The previous presto-gateway was using the gateway's URL for this (see code), which works so far in our case, and then it routes the UI calls to fetch the query details to the right coordinator cluster using the query mapping table/cache. At some point there is a request http://<gateway-url>/ui/api/query/<query_id>, which is matched by the request handler and gets sent to the right coordinator that has the query details.

Solution

I suggest one of the following:

  1. Use the externalUrl of the backend cluster for the links in the query history, and then we will need to set those to something resolvable by the expected users of the admin UI.
  2. Revert to using the gateway's URL and let the routing take care of finding the right backend cluster.

I believe the better solution is 2, so that the gateway handles all the query routing requests, same as it does for the actual execution. With 1, we will need to make sure all clusters have user-resolvable endpoints, which in our case is impossible, so we would anyway set the externalUrl to the gateway URL if that's the solution you pick.

@lambrospetrou
Copy link
Author

I can provide a PR to fix this as long as we decide on which of the two solutions you would like to use. Maybe @mosabua can chime in with a preference or route to the right folks?

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

No branches or pull requests

1 participant