Summary
GET https://graph.microsoft.com/beta/groups/{id}/members returns a response with a 500 InternalServerError object spliced directly into the middle of the JSON array, with no separating comma/brace — i.e. the response body itself is invalid JSON.
Repro
GET /beta/groups/{id}/members against any group containing at least one microsoft.graph.user member. Observed with both a B2B guest user and a native member; servicePrincipal-type members in the same response serialize fine.
Actual response body (truncated, from a Terraform provider debug/trace capture)
{"@odata.context":"...#directoryObjects","value":[{"@odata.type":"#microsoft.graph.user","id":"...", ... ,"identityParentId":null,"agentIdentityBlueprintId":null{"error":{"code":"InternalServerError","message":"The property 'isProvisionedToOnPremises[Nullable=False]' of type 'microsoft.graph.onPremisesProvisioningState' has a null value, which is not allowed.","innerError":{"date":"2026-08-03T14:03:31","request-id":"...","client-request-id":"..."}}}
Note the null{"error":...} — the error object is concatenated directly onto the previous field's value with no JSON separator, making the entire response body unparseable by any standard JSON decoder.
Impact
Any client reading this endpoint (in our case, hashicorp/terraform-provider-azuread, which depends on /beta/groups/{id}/members for azuread_group's members/owners attributes) gets a hard JSON parse failure instead of a clean HTTP error, since the malformed bytes appear inside an ostensibly-200-OK response.
Observed
- Two independent tenants/regions/groups, both reproduced consistently (not once): one in a "Poland Central" backend replica, one in "France Central".
- Confirmed via previous CI run history that the same query against the same groups succeeded as recently as 2026-07-30, and started failing consistently by 2026-08-03 with no client-side change (same provider version, same code, same group membership) — suggesting a server-side regression introduced in that window.
- The property names involved (
agentIdentityBlueprintId, onPremisesProvisioningState) suggest this may be related to the new Entra Agent ID schema additions to the user beta type.
Expected
A group members list containing user objects should serialize successfully, or fail with a clean HTTP error status — never return 200 OK with invalid JSON in the body.
Summary
GET https://graph.microsoft.com/beta/groups/{id}/membersreturns a response with a500 InternalServerErrorobject spliced directly into the middle of the JSON array, with no separating comma/brace — i.e. the response body itself is invalid JSON.Repro
GET /beta/groups/{id}/membersagainst any group containing at least onemicrosoft.graph.usermember. Observed with both a B2B guest user and a native member;servicePrincipal-type members in the same response serialize fine.Actual response body (truncated, from a Terraform provider debug/trace capture)
Note the
null{"error":...}— the error object is concatenated directly onto the previous field's value with no JSON separator, making the entire response body unparseable by any standard JSON decoder.Impact
Any client reading this endpoint (in our case,
hashicorp/terraform-provider-azuread, which depends on/beta/groups/{id}/membersforazuread_group'smembers/ownersattributes) gets a hard JSON parse failure instead of a clean HTTP error, since the malformed bytes appear inside an ostensibly-200-OK response.Observed
agentIdentityBlueprintId,onPremisesProvisioningState) suggest this may be related to the new Entra Agent ID schema additions to theuserbeta type.Expected
A group members list containing user objects should serialize successfully, or fail with a clean HTTP error status — never return
200 OKwith invalid JSON in the body.