fix: guard nil debug request in bulk check

[ivanauth]

CheckBulkPermissions panics when a DebugInformation entry with a nil
Check.Request reaches the resource-ID matching loop. This happens when a
tracing-enabled request shares a singleflight dispatch with a non-tracing
bulk check call — the combined metadata node produced by
combineResponseMetadata never sets Check.Request.

Add a nil guard to skip such entries.

Closes #3159

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[josephschorr]

LGTM

[miparnisari]

Can you explain this solution? The bug report said

Our CheckPermission calls have with_tracing: true but CheckBulkPermissions has with_tracing: false

how does this translate to if di.Check == nil || di.Check.Request == nil? if i understood correctly, in this particular issue, they would NOT be nil?

You also said

the combined metadata node produced by combineResponseMetadata never sets Check.Request.

is this not the root cause then? Why are we not fixing that?

[ivanauth]

Thank you for the feedback!

di.Check.Request actually is nil in this case. The node reaching that loop isn't the original per-resource trace node (those do have Request set). It's the wrapper node created by combineResponseMetadata, which intentionally sets fields like TraceId, SourceId, and SubProblems but leaves Request nil. The real trace entries are nested under SubProblems. The panic is consistent with that: slices.Contains(di.Check.Request.ResourceIds, ...) can only nil-deref if di.Check.Request is nil.

I don't think combineResponseMetadata is the bug. A combined node represents multiple sub-checks, so there isn't a single request to attach to it. The code also relies on Request == nil when deciding whether to flatten subproblems, so populating it would change that behavior.

The actual issue is one layer up: the singleflight key doesn't include the debug flag. That allows a with_tracing=true CheckPermission request and a with_tracing=false CheckBulkPermissions request to share the same flight, which can leak debug metadata into the bulk response.

I've reworked the fix so debug-enabled checks no longer share a singleflight flight and instead dispatch directly. That prevents debug metadata from leaking into non-debug requests and fixes the panic at the source. It also fixes the reverse case, where a tracing request could lose trace data because it shared a flight with a non-tracing request.

I kept the nil check as a defensive guard since Request == nil is still a valid shape for combined metadata nodes.

Happy to adjust the approach if you'd prefer it handled differently or close this PR completely since it's getting too complex.