fix: tolerate null allocation sets in allocation views

[markusheiden]

What does this PR change?

The allocation API returns null (instead of an empty object) as the set of days without allocation data, e.g. for windows reaching further back than the metric history:

{"code":200,"data":[null]}

The allocation report, the cost allocation chart and the cost allocation table called Object.values(set) on those sets, which throws

Cannot convert undefined or null to object

and crashes the whole view. The legacy UI handled null sets gracefully (lodash forEach on null is a no-op), the new UI regressed on this.

Guard the remaining unguarded call sites with "set ?? {}", consistent with the existing guard in runAllocationReport.

Does this PR relate to any other PRs?

opencost/opencost#4004

How will this PR impact users?

No impact.

Does this PR address any GitHub or Zendesk issues?

No.

How was this PR tested?

No tests.

Does this PR require changes to documentation?

No.

Have you labeled this PR and its corresponding Issue as "next release" if it should be part of the next OpenCost release? If not, why not?

Don't know.

AI

This PR was created using Claude Code because I don't know Go. So I hope it meets your standards.

[netlify]

✅ Deploy Preview for opencost-ui ready!

Name	Link
🔨 Latest commit	dd18ae4
🔍 Latest deploy log	https://app.netlify.com/projects/opencost-ui/deploys/6a7ed87290347c00080599e8
😎 Deploy Preview	https://deploy-preview-292--opencost-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[8silvergun]

Independent confirmation of this fix, plus one detail that I think strengthens
the case for it.

The serialisation depends on includeIdle. Same deployment, same window,
only that parameter differs:

...&accumulate=day&includeIdle=true   -> 200, buckets: [null, {2 keys}, {22}, {22}, {22}, {23}, {22}]
...&accumulate=day&includeIdle=false  -> 200, buckets: [{},   {1 key},  {21}, {21}, {21}, {22}, {21}]

includeIdle=true is the default for the Home Cost Allocation widget, so the
default path is the one that sends null.

Verified the guard against those two real responses. Running the
buildChartData branch on each, before and after set ?? {}:

includeIdle=true  (null bucket)
  before -> TypeError: Cannot convert undefined or null to object
  after  -> [2, 22, 22, 22, 23, 22]

includeIdle=false ({} bucket)
  before -> [0, 1, 21, 21, 21, 22, 21]
  after  -> [1, 21, 21, 21, 22, 21]

The before column for {} shows the leading zero-length bucket that the
existing if (!allocs.length) continue; already skips, so the guard just makes
null behave the same way. No behaviour change for the {} path.

Browser-side, unpatched, for the record — the throw lands in useMemo, so
the component's try/catch around the fetch cannot catch it and the whole page
is replaced:

TypeError: Cannot convert undefined or null to object
    at Object.values (<anonymous>)
    at oX      (/assets/dashboard-view-<hash>.js)
    at useMemo (/assets/entry.client-<hash>.js)
    at cX      (/assets/dashboard-view-<hash>.js)

console: React Router caught the following error during render, page body:
Oops! Cannot convert undefined or null to object.

Boundary tracks the null count exactly. Two snapshots three days apart as
backend history accumulated: with ~2 days of history the crash started at 4d
(1 null); with ~5 days it starts at 7d (1 null), and 3d/4d render. So the
predicate is just "does the response contain a null bucket", and every fresh
install is inside it for as many days as the default window.

Possibly worth linking: opencost-ui#291 described this same scenario and was
withdrawn as invalid because the reporter's widget was still on
includeIdle=true and hanging per opencost#3999. Turning that toggle off avoids
the hang and flips the bucket from null to {}, which is why the chart
looked fine afterwards. So #291's conclusion that "the chart handles a window
longer than the available history exactly as it should" is true only for {} —
this PR is what makes it true on defaults.

Filed as #295 so this PR has a bug report to be triaged against.