chore(reports): use CryostatContext url and headers for reportJson

[aptmac]

Welcome to Cryostat! 👋

Before contributing, make sure you have:

• Read the contributing guidelines
• Linked a relevant issue which this PR resolves
• Linked any other relevant issues, PR's, or documentation, if any
• Resolved all conflicts, if any
• Rebased your branch PR on top of the latest upstream main branch
• Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• Signed all commits using a GPG signature

To recreate commits with GPG signature git fetch upstream && git rebase --force --gpg-sign upstream/main

---

Fixes #1551

Description of the change:

Currently have this in draft while I wait for my container build to finish so I can test it with the console plugin in crc. At the moment cryostat-web looks okay in dev preview (both by itself and through a local console).

This PR updates the reportJson() to use the url and headers from CryostatContext when requesting the automated analysis.

Motivation for the change:

Without the url and headers the console plugin is unable to make the proper request in order to request the json.

[aptmac]

From the perspective of making the request and properly hitting the backend for the console plugin, this PR looks to do the trick.

From the perspective of displaying the report, it's a bit trickier. On first load the report is not cached, so the response is a 202 while the component displays a spinner.

If I "refresh" the view by opening the console global nav or switching to the Archived Recordings tab and then back, then the report will (often) display.

In the cases where it doesn't display the report, it shows the spinner again but then in the Chrome Console I see repeated:
WebSocket connection to 'wss://console-openshift-console.apps-crc.testing/api/proxy/plugin/cryostat-plugin/cryostat-plugin-proxy/upstream/api/notifications?tab=active-recording&ns=cryostat-project-2&name=mycryostat2' failed: Insufficient resources

and in the plugin backend:

WebSocket Upgrade: /upstream/api/notifications?tab=active-recording&ns=cryostat-project-2&name=mycryostat2
WebSocket /api/notifications?tab=active-recording&ns=cryostat-project-2&name=mycryostat2 -> https://mycryostat2.cryostat-project-2:443
WebSocket Upgrade: /upstream/api/notifications?tab=active-recording
Error: Proxy request from undefined /upstream/api/notifications?tab=active-recording requested <undefined, undefined> - values cannot be falsey
    at getCryostatInstance (/opt/app-root/src/server.js:114:15)
    at /opt/app-root/src/server.js:245:26
    at Generator.next (<anonymous>)
    at /opt/app-root/src/server.js:41:71
    at new Promise (<anonymous>)
    at __awaiter (/opt/app-root/src/server.js:37:12)
    at Server.<anonymous> (/opt/app-root/src/server.js:234:40)
    at Server.emit (node:events:518:28)
    at onParserExecuteCommon (node:_http_server:947:14)
    at onParserExecute (node:_http_server:848:3)

Will continue looking into this one

[andrewazores]

I think the values cannot be falsey is probably related to cryostatio/cryostat-openshift-console-plugin#88 and the context de-selection bug. If that part is all working properly then there should always be a properly selected Cryostat instance, and its name and namespace should be used by the NotificationChannel when it tries to open a WebSocket connection (as seen earlier in the log). I'm not sure what failed: Insufficient resources is about, though. In any case, if the connection is not opened or somehow is severed, then the client code will not be notified that the report generation has completed and it will therefore never trigger a re-fire of the report request, which is what should normally clear the loading spinner and display the actual content.

[andrewazores]

^ cryostatio/cryostat#286 (comment)

In this case, the expected flow is:

1. Client sends a GET
2. Server receives the request, starts processing the report, and responds with HTTP 202 with a job ID
3. Client receives the 202 and job ID, and starts listening for a WebSocket notification indicating completion of that ID
4. After some time, server completes processing, storing the result in a cache and emitting a notification with the job ID
5. Client receives the notification with the expected job ID and fires the GET request again
6. Server receives the GET request and finds the result is in the cache, and returns that with a 200

[aptmac]

Thanks for the breakdown of the paths, I was missing updated urls and headers further down the chain for handling the 202 response. This looks to be running okay now.

While testing in crc I was looking into some of the timings, because you had noticed the increase in build time lately. It looks like most of the time is spent doing npm install, even the change to not build cryostat-web dependencies in the console plugin CI saved about 4 minutes. For the plugin itself, it spends roughly 5 minutes npm install-ing, another minute with the subsequent yarn install, and then the actual yarn build tends to take about 2.5 minutes on my machine. It'd be nice to eliminate that first npm install if we're going to use yarn anyways, although it doesn't look as simple as just removing it at the moment.

Preview: