Optimize Test - 21877

[Manoj Kesana (Manoj-Kesana)]

No description provided.

[Copilot]

🟡 Changes recommended

The batching still over-fetches, reports misleading failure identifiers, and lacks required Pester coverage.

1 open finding

• Evaluate early-stop limit after each Graph batch · New

What changed in this PR

Optimizes assessment 21877 by batching sponsor lookups and limiting reported sponsorless guests.

Changes:

• Normalizes database results to an array.
• Replaces per-user Graph calls with batched requests.
• Caps sponsorless-user details at 20.

File	Description
src/​powershell/​tests/​Test-Assessment.21877.ps1	Adds batched sponsor lookup and bounded reporting.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

Batch failures incorrectly report the internal batch ID as the guest ID.

0 open findings

1 resolved since last review

• Evaluate early-stop limit after each Graph batch

Previously missed (1)

In code that hasn't changed since last review

Failure path reports batch sequence ID instead of guest ID

src/​powershell/​tests/​Test-Assessment.21877.ps1:71

Invoke-ZtGraphBatchRequest -Matched returns the original input in Argument on success, but its failure paths return the generated batch request instead (Invoke-ZtGraphBatchRequest.ps1:687-715). Therefore Argument.id here is the batch sequence ID, not the guest ID, and a server-side failure will identify the wrong guest. Resolve the guest from the matched result ID (or change the helper contract) before constructing this error.

🧠 Review effort: Balanced

[Aleksandar Nikolić (alexandair)]

Manoj Kesana (@Manoj-Kesana) Please, address my feedback.

Anton Staykov (@astaykov) Just for the record:

The batching helper has known problems with missing responses and retries

This assessment now uses the batching helper directly. That helper has existing problems that are already being handled separately:

• If Graph omits a response for one request in a batch, the helper sends that request again. There is no limit on these repeated attempts, so the assessment may keep running until a timeout or manual stop ends it. The offline check confirmed that the request was sent again, then stopped the next attempt deliberately. It did not leave the assessment running to demonstrate a hang.
• The previous individual requests used the repository's Invoke-ZtRetry function (Invoke-ZtGraphRequestCache.ps1#L121). The batching helper calls the Graph SDK directly (Invoke-ZtGraphBatchRequest.ps1#L581), without that function. This removes the repository's additional retry handling when sending the batch fails. The SDK may still retry the batch itself; this review did not test those SDK retries against Graph.

The helper does retry individual requests that receive HTTP 429, meaning Graph is limiting the request rate. That behavior passed an offline check with no retry delay. It does not establish that temporary server errors, such as HTTP 503, will also be retried.

There are planned fixes for missing responses and failed-batch retries in PR #1584 follow-up. Those fixes should be separately tracked. They are relevant risks for this assessment, but they are not new defects introduced by PR #1592 or additional reasons to block it.

[Copilot]

🟢 Approval recommended

No blocking issues were identified in the batching logic or result-status handling.

0 open findings

🧠 Review effort: Balanced

[Aleksandar Nikolić (alexandair)]

LGTM