Created attachment 1676577 [details] vm creation screen Description of problem: After VM creation, when clicking to view the newly created VM, one of the requests return 404. The VM page is successfully displayed. Version-Release number of selected component (if applicable): 4.4.0-rc.6 CNV 2.3 How reproducible: 100% Steps to Reproduce: (open browser dev console using F12) 1. From the UI, create a VM using the Wizard 2. Click on "See virtual machine details" on the "Successfully created virtual machine" screen. Actual results: One of the page requests return 404. Expected results: No errors. Additional info: See attached error
since there is no user facing error or functionality gap, only an ugly stack trace in the logs, moving to 4.5
@Nelly, FYI
ack
notes: the 404 request is for the VMI [1], when the VM is just created ( or if it's not running ) we will not have a VMI. Since we can not know if a VM has or has not a VMI at this stage, we test by queering a maybe missing VMI sounds OK, [1] https://github.com/openshift/console/blob/master/frontend/packages/kubevirt-plugin/src/components/vms/vm-details-page.tsx#L92 @Tomas can we close it as not a bug ?
well, we still show the stack what is ugly. If we can not swallow the error in this case, than I would close it as "cant fix" instead of "not a bug" since it is a bug we can not fix.
@Tomas thanks, leaving open for now.
This should be fixed in core console. There should be at least an option in co-fetch to suppress 404 errors. (FirehoseResource already has optional prop to use/infer from). Then it can be fixed in all resources which are optional consistently. Many of these unnecessary 404 errors are found throughout the whole codebase and could be cleaned up a bit.
> There should be at least an option in co-fetch to suppress 404 errors. sounds useful to me > This should be fixed in core console. Filip, can you open a BZ on management-console ?
done: https://bugzilla.redhat.com/show_bug.cgi?id=1836956
Verified in console release-4.5 branch commit: 5994c64ee529b650bae348ef78ebc23dca8db5c5 No 404 responses observed when navigating to newly created VM
The console message is both accurate and harmless. It's not displayed to the user. We shouldn't be changing the logic to avoid such messages. In fact, I personally think it's *worse* to suppress the message because it makes debugging problems harder. We should probably revert this change.
We should handle the failed promise in the code if we're not, which should avoid the stack trace. But we shouldn't switch to a list request.
> The console message is both accurate and harmless. VMI is owned by VM, it is perfectly ok to have the option to a list of owned objects without getting a 404 response if the list is empty. Without this change, each time the VM has an empty list of VMIs we get a 404 message. In our case this is not accurate, for example, we will not get such a 404 message for a list of owned Pods if we state they are **optional** In our case it can also be harmful, it can obscure a real problem in the logs with lots of false-positive 404 lines. > we shouldn't switch to a list request. IMHO Listing all owned objects instead of just the first one is an OK solution in our use case (even if max size for this list is currently one).
The reason for Firehose `optional` is to prevent an error screen from being displayed to the user on errors. `coFetch` doesn't do that, so it's not needed there. When you say a 404 message, you mean specifically in the JS console, right? Not anything displayed to the user? Are you handling the failed promise from `coFetch`? (If not, that's a bug imo.)
You would need to handle the failed promise regardless to be able to check for 404 errors vs. other errors that you want to surface to the user.
> When you say a 404 message, you mean specifically in the JS console, right? Not anything displayed to the user? Yes, the code path is valid, no error or un-handled promise in the code, and user is not notified, a VM not owning any VMIs is normal. the only problem is that a user debugging some other problem will see false 404 responses for queering an obj we know may not exist. > You would need to handle the failed promise regardless to be able to check for 404 errors vs. other errors that you want to surface to the user. We do not have a failed promise. the code is fine with VM not having owned VMIs
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1836956, it is not possible to handle logging of 404 errors with current implementation of Firehose.
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, 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/RHBA-2020:2409