Repository navigation
backstage-coder: With Backstage and Coder deployed on the same cluster, HTTP responses are formatted as HTML #142
Description
Activity
Investigating now
- changed the title
[-]backstage-coder: With Backstage and Coder deployed on the same cluster, HTTP responses are formatted as JSON[/-][+]backstage-coder: With Backstage and Coder deployed on the same cluster, HTTP responses are formatted as HTML[/+]on Oct 2, 2024 Updating issue with current findings: we have a pretty good idea of where the issue is coming from, but still aren't completely sure about the best path for fixing it.
The issue seems to be that when Backstage is deployed on a subpath (e.g.,
deployment.com/internal/backstagerather thandeployment.com), the proxy logic is failing. That is, our Backstage plugin makes a request to the built-in Backstage proxy, the proxy generates a new URL that it thinks is right, but then that URL (1) doesn't actually exist and (2) doesn't start with/api. Then, because the Coder core application is a React app, the server is set up to serve an HTML page for any non-API routes. The Coder server sends back the HTML file, the Backstage plugin tries to parse it as JSON and fails, and then the user is effectively locked out of the plugin.We previously thought that the issue was that the data was correct but was just in the wrong format. I think we've ruled that out now.
One band-aid fix is to update the Backstage
app-config.yamlfile to change how the proxy forwards the URL. This seems to do the trick, but we were under the impression that for certain categories of URLs, the built-in Backstage proxy would just magically take care of them, even with some URLs are several segments deep.
Currently confirming with the customer whether updating the
app-config.yamlfile is enough to unblock them. Then, once we have confirmation, we'll be reaching out to the Backstage team for guidance on ways to make the proxying logic smarter and more automatic. The thing that has me most concerned is that the customer said our plugin was the only one that had this issue, out of all the third-party plugins they had installed.Waiting to hear back from user.
Throwing this on for the current sprint. We got some more context from other customers (one of whom is a paid customer), so I'm going to be leveraging some of the info we got from ZenDesk
Going to hold off on working on this until I have a support call with a customer tonight. They were able to fix the problem on their own, but their solution might be able to provide some guidance on how to fix this for other users
Hey @Parkreiner - did the call lead to any ideas on what may have been the issue?
@bpmct Sorry, forgot to reply to this earlier
Sadly, there wasn't really much else that got unearthed from the call. The issue in HK's case was that they had a config value set wrong in the main Backstage library, and that was causing our plugin to freak out a little bit. They were able to figure out the fix on their own, thoughThey did run into another issue involving auth state not working as expected. I'm going to do some digging into it tomorrow, and open up an issue if need be
Reacted by Ben Potter
Opening this issue on behalf of a customer.
Issue
We have a customer reporting an issue when both Backstage and Coder are deployed on the same Kubernetes cluster, particularly when the Backstage deployment is not being served from the root URL. With the deployments configured like this, the Coder plugin will still make HTTP requests, but the responses will be formatted as
text/htmlinstead ofapplication/json.In addition, the response body is the root HTML file we serve for the Coder deployment dashboard UI. This causes the plugin to break in different ways depending on the version of the Coder plugin. On v0.3.0, the incorrect response causes the plugin to boot the user to the token authentication screen, with no way for them to get to any other views. On earlier versions, the incorrect response still lets the user reach the workspaces list view, but the view is never able to render any workspaces. The v0.3.0 behavior seems "more correct", but we still need to make sure that responses come back in the correct format.
This issue is also almost definitely on our end. The customer reported that out of all the plugins they're using, this is the only one that has this issue.