Opening this issue on behalf of a customer. Will start looking into addressing this on Monday.
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/html instead of application/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.
Steps to reproduce
Will update issue once I have a chance to look into this.
Opening this issue on behalf of a customer. Will start looking into addressing this on Monday.
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/html
instead 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.
Steps to reproduce