#1553 Add check for stale data in session storage for selected bias charts

[alexcreasy]

Closes:

• [BUG] Bias metric chart selector shows a selected, non-existent chart when metrics are deleted by direct call to the TrustyAI API #1533

Description

When the bias page renders, any selected charts in the browser session storage are validated to ensure they still exist i.e. they haven't been deleted by a direct call to a backend API.

How Has This Been Tested?

Pre-requisites:

• A DSProject with:
  • TrustyAI installed
  • a demo model installed
  • some demo data sent to the model
  • at least one bias metric configured

Instructions are for Chrome, it's possible with any browser but you'll have to figure out manipulating the session storage yourself in any others:

1. Navigate to the bias metrics tab
2. From the selector, select a chart
3. Open the browser console (F12) -> Applications tab
4. From the 'storage' group on the left menu bar, expand 'Session Storage'
5. In the main tab, look for a key that will be of the format: 'odh.dashboard.xai.selected_bias_charts-$MODEL_NAME'
6. Copy the key and value into a text editor for later use.
7. Back on the dashboard, click the configure button and delete the bias metric you selected in step 2.
8. Click the "back to $MODEL_NAME" button in the top right to return to the charts section.
9. Go back to the browser console -> applications -> session storage like in steps 3 & 4
10. Re-add the key and value you pasted in steps 5 & 6
11. refresh the page.
12. Validate that the Metrics to display dropdown is both disabled and does not show any selected charts.

Test Impact

This is a small bug fix and there are no tests as yet for this feature.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

• Included any necessary screenshots or gifs if it was a UI change.
• Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

• The developer has tested their solution on a cluster by using the image produced by the PR to main

Use image: quay.io/acreasy/odh-dashboard:issue-1553

[alexcreasy]

/HOLD

There's a bug in this, apparently I forgot the basics of equality by reference 🤦‍♂️ - this isn't going to work after an object is deserialised from the session store. I'll raise a fix shortly.

[alexcreasy]

This is ready for review now

[pnaik1]

Before:

After:

Working Fine
@alexcreasy is there anything else I need to check here?

[alexcreasy]

@pnaik1 no that works as expected, if you could do a code review and give it an lgtm if you're happy that would be great!

[pnaik1]

code looks good
/lgtm

[alexcreasy]

/APPROVE

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexcreasy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [alexcreasy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment