使用Graph API在委托日历创建事件时触发InternalServerError

• 端点路径上下文与委托日历的归属不匹配
  你使用的/me/calendars/{calendarId}/events路径，上下文绑定的是当前授权用户的自有日历域。当传入的calendarId属于其他用户共享的委托日历时，Graph服务端会在跨域路由校验时出现内部逻辑冲突。你之前用错误token、错误calendarId测试时，请求会直接被网关层拦截返回401/404，根本不会走到内部服务处理分支，所以复现不了这个异常。
• 请求体冗余空值触发严格校验异常
  实际发送的Payload中，location、attendees对象包含大量值为null的可选字段（如address、coordinates、proposedNewTime、status、transactionId）。处理自有日历时，Graph会自动忽略这类空值字段；但处理委托日历时，服务端对请求体的schema校验逻辑更严格，遇到预期外的空字段、以及和委托场景冲突的isOrganizer: true字段（当前用户作为委托操作方，并非事件的原生组织者，强制传入该字段会触发内部状态矛盾），就会抛出无明确错误信息的InternalServerError。
• 时区配置逻辑冲突
  你传入的start/end字段中，dateTime值带的是+13:00的新西兰时区偏移，但timeZone字段配置的是“Pacific Standard Time”（美西太平洋标准时间，对应UTC-8偏移）。处理自有日历时，服务端会优先取dateTime自带的偏移值完成时间换算，容忍度更高；处理委托日历时，服务端会优先强制使用timeZone字段定义的时区做时间校验，两者数值不匹配就会触发服务端时间计算的内部异常。
• 资源类参会人的权限缺失
  你将karlo@tapnztest.onmicrosoft.com设置为type="resource"类型的参会人，这类参会人对应会议室、设备类的资源邮箱。自有日历创建事件时，系统会自动绕过资源权限校验直接发送邀请；委托日历创建事件时，系统会在尝试给资源邮箱发送参会邀请的环节校验当前用户的权限，一旦权限不足就会抛出未捕获的服务端异常。

• 替换委托日历的专属调用端点
  不要使用/me/calendars/{calendarId}/events路径操作其他用户的委托日历，将路径中的/me/替换为被委托日历所有者的用户标识，最终路径为：
  https://graph.microsoft.com/v1.0/users/{被委托日历所有者的邮箱地址}/calendars/{calendarId}/events
  结合你代码中的场景，被委托的日历所有者是test@tapteam.co.nz，直接替换路径段即可。
• 精简请求体结构
  序列化请求时移除所有值为null的可选字段：
  • location对象仅保留实际使用的displayName属性，删掉所有空值字段
  • 移除isOrganizer: true字段，该字段是Graph返回事件时的只读属性，创建请求传入会直接触发校验错误
  • attendees对象仅保留有实际值的emailAddress、type属性，删掉proposedNewTime、status这类空值字段
  • 移除空的transactionId字段
• 修正时区配置一致性
  保证dateTime字段的时间偏移和timeZone字段的时区定义逻辑统一：
  要么dateTime传不带时区偏移的本地时间字符串，timeZone配置和实际时间匹配的时区（如新西兰场景就传“New Zealand Standard Time”）；要么直接把timeZone设为“UTC”，dateTime传带标准时间偏移的字符串，避免两者逻辑冲突。
• 匹配参会人类型的权限要求
  如果karlo@tapnztest.onmicrosoft.com是普通用户参会，就把参会人type从"resource"改为"required"或"optional"；如果确实需要添加资源类参会人，先确认当前授权用户对该资源邮箱有合法的日历访问权限，否则不要在委托日历的事件创建请求中添加这类参会人。

内容的提问来源于stack exchange，提问作者X Crespo