‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

$expand for singleValueExtendedProperties should include an $filter and use a stable property ID

Microsoft Graph generally requires filtering extended properties by id when expanding; expanding without a filter is unsupported/inefficient and often rejected. Also, your current writer uses a random GUID for the property set ID, making it impossible to filter/round‑trip reliably.

Apply this diff (assumes you export a stable constant MICROSOFT_BLOCKED_TIME_PROP_ID from ./microsoft-calendar/events):

-        .expand("singleValueExtendedProperties")
+        .expand(
+          `singleValueExtendedProperties($filter=id eq '${MICROSOFT_BLOCKED_TIME_PROP_ID}')`
+        )

This ensures the events list returns only the blockedTime property and keeps OData semantics correct.

🌐 Web query:

Does Microsoft Graph require $filter on $expand=singleValueExtendedProperties for events? Provide an official doc snippet or example.

💡 Result:

Yes, Microsoft Graph requires a $filter when using $expand=singleValueExtendedProperties for events if you want to retrieve specific extended properties. This is explicitly documented in the official Microsoft Graph docs and confirmed by multiple support threads.

Official documentation states:

Using the query parameter $expand allows you to get the specified resource instance expanded with a specific extended property. Use a $filter and eq operator on the id property to specify the extended property. This is currently the only way to get the singleValueLegacyExtendedProperty object that represents an extended property[5].

Example from the official docs:

GET https://graph.microsoft.com/v1.0/me/events?$expand=singleValueExtendedProperties($filter=id eq 'String {GUID} Name CustomProperty')

This request will expand the event with only the extended property matching the given id[5][8].

Community threads and support answers clarify:

• You cannot simply include all singleValueExtendedProperties by using $expand=singleValueExtendedProperties without a filter; you must specify the property id using a filter[3][8].
• Without a filter, the response will not include extended properties[3].
• This is by design; the API requires you to explicitly filter for the property you want to expand for events (and other resource types like messages)[5][8].

Representative code snippet from a support answer:

.Expand("singleValueExtendedProperties($filter=id eq 'String {GUID} Name MyExtendedProperty')")

Retrieves only the extended property with the specified id for each event[8].

In summary:
Yes, a $filter is required on $expand=singleValueExtendedProperties when querying events in Microsoft Graph—there is no supported way to expand all extended properties without specifying a filter by property ID[3][5][8].

Reference - official documentation snippet:

"Use a $filter and eq operator on the id property to specify the extended property. This is currently the only way to get the singleValueLegacyExtendedProperty object that represents an extended property."
— [Microsoft Graph Docs: Get singleValueLegacyExtendedProperty][5]

If you need to retrieve all singleValueExtendedProperties for an event, the Graph API currently does not support a wildcard or omitting the filter; you must query those properties individually by their ID[3][5][8].

Citations:

• 1: https://learn.microsoft.com/en-us/answers/questions/1809278/issue-with-retrieving-singlevalueextendedpropertie
• 2: https://learn.microsoft.com/en-gb/answers/questions/2084527/how-to-expand-singlevalueextendedproperties-on-mes
• 3: https://learn.microsoft.com/en-us/answers/questions/1467708/when-using-singlevalueextendedproperties-can-i-get
• 4: https://learn.microsoft.com/en-us/answers/questions/2282685/cannot-get-singlevalueextendedproperties-from-to-t
• 5: https://learn.microsoft.com/en-us/graph/api/singlevaluelegacyextendedproperty-get?view=graph-rest-1.0
• 6: https://learn.microsoft.com/en-us/graph/api/singlevaluelegacyextendedproperty-post-singlevalueextendedproperties?view=graph-rest-1.0
• 7: https://learn.microsoft.com/en-us/answers/questions/1118527/ms-graph-api-filter-calendar-events
• 8: https://learn.microsoft.com/en-us/answers/questions/462964/how-to-expand-microsoft-graph-extended-properties
• 9: https://learn.microsoft.com/en-us/answers/questions/2278386/extended-properties-missing-from-attendee-calendar
• 10: https://learn.microsoft.com/en-us/answers/questions/1420756/add-singlevalueextendedproperties-or-open-extensio

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Remove $expand from POST create; prefer return=representation if you need the created entity

OData options like $expand are not guaranteed on POST. To receive the created event, rely on Prefer: return=representation. Since you already serialize singleValueExtendedProperties in the request body, Graph will persist them; if you need them immediately, follow with a GET using $expand + $filter.

Apply this diff:

-        .api(`${calendarPath(calendar.id)}/events`)
-        .expand("singleValueExtendedProperties")
-        .post(toMicrosoftEvent(event));
+        .api(`${calendarPath(calendar.id)}/events`)
+        .header("Prefer", 'return=representation')
+        .post(toMicrosoftEvent(event));

Optional: If you must guarantee the extended property in the response, perform a subsequent GET with the same $expand($filter=...).

🌐 Web query:

Does Microsoft Graph support using $expand on POST requests? What is the recommended way to get a representation of the created entity, including extended properties?

💡 Result:

Microsoft Graph does not support using $expand on POST requests; $expand is limited to GET queries and cannot be used to get expanded data in the response of a create (POST) call[7][1]. To obtain a representation of the newly created entity—including extended properties—the recommended approach is to issue a GET request for the entity and use $expand in that request.

Details

• $expand in Microsoft Graph:
  The $expand query parameter is documented as only working for GET requests where you fetch an entity and want to include its related (navigation) properties[1][7]. The documentation and SDK examples show usage only with GET endpoints, e.g. GET /me/messages/{message-id}?$expand=attachments[1][7]. There is no mention or example of $expand with POST[1][7].

• POST request behavior:
  When you create an entity via a POST request (e.g., creating a message, event, etc. with extended properties), the API response generally contains only the representation of the entity itself—not its expanded navigation properties or extended properties unless those are part of the main entity or specified in the request body[2][5].

• Extended properties (single- and multi-value):
  To add extended properties when creating an entity, you include them in the initial POST request body[5][2]. However, to read all extended properties on the entity (especially those that are part of navigation properties), you need to do a follow-up GET with $expand[6][9]. For example:

  • After creating a message with extended properties, make a GET /messages/{id}?$expand=singleValueExtendedProperties,multiValueExtendedProperties request to retrieve the full representation including those properties[6][9].
  • This is described as "the only way to get the multiValueLegacyExtendedProperty object that represents an extended property"[6].

Workflow Recommendation

1. POST to create the entity (including any extended properties in the request body, if supported)[5][2].
2. GET the entity with $expand to retrieve the full representation, including extended properties:

   GET /messages/{id}?$expand=singleValueExtendedProperties,multiValueExtendedProperties
   

   This pattern is necessary because $expand is not permitted or supported in POST requests[7][1][6].

Additional Considerations

• This limitation applies to all query options in Graph: only certain ones (e.g. $select, $expand, $filter) are permitted in GET requests[7][1].
• For some resources, extended properties must be specifically requested via $expand or otherwise are not included in the default GET response[6][9].

Summary Table:

This approach is explicitly confirmed in Microsoft Graph documentation regarding extended properties and $expand usage[1][5][6][7][9].

Citations:

• 1: https://learn.microsoft.com/en-us/graph/sdks/create-requests
• 2: https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/v1.0/api/multivaluelegacyextendedproperty-post-multivalueextendedproperties.md
• 3: https://learn.microsoft.com/en-us/graph/api/application-post-extensionproperty?view=graph-rest-1.0
• 4: https://learn.microsoft.com/en-us/answers/questions/1010008/filtering-and-expanding-users
• 5: https://learn.microsoft.com/en-us/graph/api/singlevaluelegacyextendedproperty-post-singlevalueextendedproperties?view=graph-rest-1.0
• 6: https://learn.microsoft.com/en-us/graph/api/multivaluelegacyextendedproperty-get?view=graph-rest-1.0
• 7: https://learn.microsoft.com/en-us/graph/query-parameters
• 8: https://learn.microsoft.com/en-us/graph/api/resources/extended-properties-overview?view=graph-rest-1.0
• 9: https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/beta/api/singlevaluelegacyextendedproperty-get.md
• 10: https://learn.microsoft.com/en-us/answers/questions/1015788/expand-sometimes-does-not-return-all-the-data

Remove $expand from PATCH update; ensure you get a representation

Similar to create, $expand on PATCH is not reliable. If you need the updated entity, use Prefer: return=representation, or re-fetch via GET with $expand($filter=...).

Apply this diff:

-        .api(`${calendarPath(calendar.id)}/events/${eventId}`)
-        .expand("singleValueExtendedProperties")
-        .patch(toMicrosoftEvent(event));
+        .api(`${calendarPath(calendar.id)}/events/${eventId}`)
+        .header("Prefer", 'return=representation')
+        .patch(toMicrosoftEvent(event));

Follow-up: If the API still returns 204 No Content depending on resource, perform a GET to fetch the updated record with $expand($filter=...).

🌐 Web query:

When updating an event via Microsoft Graph, does PATCH return a representation by default, or is Prefer: return=representation required? Cite official docs.

💡 Result:

When updating an event via Microsoft Graph using PATCH, the response does not return a resource representation by default; instead, it returns a 204 No Content by default unless you include the Prefer: return=representation header[2]. The official documentation for PATCHing events does not specify that a representation is returned unless the Prefer header is used[10].

Supporting details:

• According to Microsoft’s OData-conformant endpoint behavior, PATCH (for resources like users, events, planner plans, and others) typically responds with 204 No Content unless Prefer: return=representation is specified[2][8]. This is also observed for event update operations.
• The GitHub version of the official event-update doc and API request samples show PATCH requests without the Prefer header, and in practice, these result in a 204 response.
• An official Microsoft tech community discussion confirms: "When patching a user (and probably many other things), the Graph API will always return 204 No Content, even when adding the header Prefer: return=representation. This however is not following the OData specification"[2]. This suggests even specifying Prefer might not always work as expected for certain resources, but the documented intent is that Prefer is required for representation.

In summary: PATCHing an event in Microsoft Graph returns 204 No Content by default; use Prefer: return=representation if you require the updated resource returned in the response[2][10].

Citations:

• 1: https://learn.microsoft.com/en-us/answers/questions/2200306/urgent-issue-with-patching-of-calendar-invites-on
• 2: https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/graph-api-should-return-full-content-when-patching-with-prefer/idi-p/3771966
• 3: https://llvm.org/docs/LangRef.html
• 4: https://learn.microsoft.com/en-us/answers/questions/1192822/how-to-update-an-occurrence-of-a-meeting-using-gra
• 5: https://learn.microsoft.com/en-us/graph/api/plannerplandetails-update?view=graph-rest-1.0
• 6: https://www.keycloak.org/docs/latest/upgrading/index.html
• 7: https://learn.microsoft.com/en-us/graph/api/group-update-event?view=graph-rest-1.0
• 8: https://learn.microsoft.com/en-us/graph/api/plannerplan-update?view=graph-rest-1.0
• 9: https://cloud.google.com/chronicle/docs/reference/udm-field-list
• 10: https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/main/api-reference/v1.0/api/event-update.md

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.