Hot Fix: Guard clinical & genomic search against nodes missing discovery counts

[mshadbolt]

Problem

On the clinical & genomic search page, a node can return clinical results but no matching discovery counts for the same site — e.g. the node is offline, timed out, returns a 403 from federation (Request claims to be from federation but it's not), or its location.name differs between the discovery and clinical responses.

When that happens, handleCensoring in dataVisualization.jsx indexed the discovery counts object by program id (dataObj[siteName][program]) without checking the per-site bucket existed. dataObj[siteName] is undefined, so the access throws:

Cannot read properties of undefined (reading 'AML')

(where AML is whatever the first program id is). The error boundary catches it and white-screens the entire search page with "Something went wrong".

This was seen in production when a federated node's query service rejected the federation service token and returned no discovery counts.

Fix

In the clinical fill-in loop:

• Resolve site.summary?.[dataKey] once and skip nodes that have no summary for the category — this also avoids an Object.keys(undefined) throw.
• Skip the object (stacked-chart) fill-in when there is no matching discovery bucket for the site.

Behaviour is unchanged when the discovery and clinical responses agree on the sites. This is defence-in-depth: the affected node still renders with no counts until its backend issue is resolved, but the page no longer crashes for every other node.

Notes

• Branched off stable, which already carries the Highcharts header fix #14 censoring fix (Fix Highcharts #14 on censored aggregate charts #269); this adds the missing undefined-bucket guard that Fix Highcharts #14 on censored aggregate charts #269 did not cover.
• ESLint passes clean.

🤖 Generated with Claude Code

[SonQBChau]

This only fixes the surface problem e.g the data-portal display. It does not fix the underlaying issue why federation failed and we need that for the node to function. I would reject the fix for 2 reasons:

• It would mask the real error and make it difficult to see the real one. No other nodes need this fix except BC, and it still need to fix federation
• It merges directly into stable which I don't like, would other nodes require this fix too? What about the version drift between them. Sure we can remember it now, but if every site has 1-2 hotfix, it will be a mess later.

[mshadbolt]

If we don't fix it that means every time one connected node has this issue that the whole network is non-functional. The whole definition of a hot fix is that it is a fix that is needed on stable immediately. Yes all nodes need the fix.

[SonQBChau]

LGTM