Bug 1964941

Summary:	If loading dynamic plugin times out, the UI throws a syntax error
Product:	OpenShift Container Platform	Reporter:	Tomas Jelinek <tjelinek>
Component:	Management Console	Assignee:	Samuel Padgett <spadgett>
Status:	CLOSED ERRATA	QA Contact:	Yadan Pei <yapei>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.8	CC:	aos-bugs, jokerman, spadgett, yapei
Target Milestone:	---
Target Release:	4.9.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-18 17:31:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1982221

Description Tomas Jelinek 2021-05-26 12:01:57 UTC

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

Comment 1 Samuel Padgett 2021-05-26 18:35:23 UTC

*** Bug 1964980 has been marked as a duplicate of this bug. ***

Comment 3 Samuel Padgett 2021-07-13 15:07:54 UTC

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.

Comment 4 Samuel Padgett 2021-07-13 15:15:14 UTC

> 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.

Comment 6 Yadan Pei 2021-07-16 09:51:23 UTC

the timeout is changed to 120 seconds, moving to VERIFIED to see if we have same issue in later testing

Comment 9 errata-xmlrpc 2021-10-18 17:31:45 UTC

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