Description of problem: The timeout for loading a dynamic plugin is hardcoded 10 seconds. If the plugin does not load in this time, the UI receives an incomplete JS and fails on syntax error. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. have a dynamic plugin which loads longer than 10 seconds 2. load the UI Actual results: 1: The UI fails on a syntax error 2: There is no way to configure a longer timeout - e.g. no command line option while starting the bridge process to workaround the issue 3: The 10s timeout feels like a bit too small for larger production setups Expected results: 1: The UI will log an error saying that the plugin failed to load due to a timeout 2: There is a command line option to run the bridge with a longer timeout 3: The default timeout is much longer than 10s. Additional info: The timeout is in pkg/server/server.go
*** Bug 1964980 has been marked as a duplicate of this bug. ***
I think the real issue here is that the timeout is simply unreasonably short. We should increase it to something like 60s or longer. I'm a little unsure why you get a partial response. http.Client Timeout does say > The timer remains running after Get, Head, Post, or Do return and will interrupt reading of the Response.Body. https://pkg.go.dev/net/http#Client I guess reading Response.Body is getting interrupted. We do check for errors when we call `io.Copy`, however. https://github.com/spadgett/console/blob/0b4ecab1e5d66e0924df6e83838a1e5d1230051e/pkg/plugins/handlers.go#L70 I don't know if there is a way to detect that we got a partial response if there is no error. Regardless, the request will fail (either because the server returns an HTTP status error or due to a syntax error with a partial response). There might be cases where it's better to get the partial response as well, perhaps for CSS or images? The partial JS response does not break console. It only prevents the plugin from loading. I'd propose we simply increase the timeout.
> The UI will log an error saying that the plugin failed to load due to a timeout This is going to be handled as a separate story where we show that a plugin was not loaded (for any reason) in the notification drawer. > There is a command line option to run the bridge with a longer timeout If we use a more reasonable default, is this needed? I'd rather increase the default for now. We can revisit this later if we find there is a need.
the timeout is changed to 120 seconds, moving to VERIFIED to see if we have same issue in later testing
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.9.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3759