Skip to content

WPB-26705: move meeting qualified id to event envelope - #5349

Merged
blackheaven merged 6 commits into
developfrom
gdifolco/WPB-26705-meeting-events-fix
Jul 21, 2026
Merged

WPB-26705: move meeting qualified id to event envelope#5349
blackheaven merged 6 commits into
developfrom
gdifolco/WPB-26705-meeting-events-fix

Conversation

@blackheaven

Copy link
Copy Markdown
Contributor

https://wearezeta.atlassian.net/browse/WPB-26705

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

@blackheaven
blackheaven marked this pull request as ready for review July 20, 2026 15:11
@blackheaven
blackheaven requested review from a team as code owners July 20, 2026 15:11
The meeting create/update/delete events rendered the meeting's Qualified MeetingId bare as the data field ({"id","domain"}), unlike every other Qualified value in the API, which lives under a qualified_id field. Wrap it via a schema-only change (the EventData/Event data-types are unchanged) using a new meetingEventDataSchema helper, so data is now {"qualified_id":{"id","domain"}}. FromJSON/ToJSON share the single schema, so the roundtrip is symmetric and producers pick up the wrapping automatically.

Adds golden tests pinning the wire shape for all three meeting events.
@blackheaven
blackheaven force-pushed the gdifolco/WPB-26705-meeting-events-fix branch from 80cb03d to db282fe Compare July 20, 2026 15:14
@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Jul 20, 2026
Comment on lines +3 to +8
"data": {
"qualified_id": {
"domain": "example.com",
"id": "00000001-0000-0000-0000-000000000001"
}
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't want nesting.

Suggested change
"data": {
"qualified_id": {
"domain": "example.com",
"id": "00000001-0000-0000-0000-000000000001"
}
},
"qualified_id": {
"domain": "example.com",
"id": "00000001-0000-0000-0000-000000000001"
},

Meeting lifecycle notifications (meeting.create/update/delete) previously
reused the conversation event envelope, nesting the meeting id as
data.qualified_id. Extract a dedicated Wire.API.Event.Meeting event type
whose envelope carries qualified_id flat at the top level, with no "data"
wrapper.

- Add Wire.API.Event.Meeting (Event/EventType), mirroring the conversation
  schema idiom but with a flat qualified_id field and no tagged type/data
  dispatch or subconv.
- Remove the meeting lifecycle variants from Wire.API.Event.Conversation
  (EventType, EventData, the enum, and the meeting schema). The distinct
  conversation.create-meeting event is retained.
- Retarget the meetings producer (pushMeetingEvent) to build the new event;
  the three call sites pass Create/Update/Delete.
- Move the meeting golden values into a dedicated MeetingEvent module and
  flatten the golden JSON (qualified_id at top level, no data wrapper).
- Strengthen the integration assertions to prove payload.0.qualified_id is
  present and payload.0.data is absent.

Unreleased feature (PR #5349), so this is a clean cutover with no back-compat
migration.

@fisx fisx left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is about making Meeting events their own category, separate from conversations. The changes make sense to me and I've convinced myself of internal consistency (the tests are all there).

What worries me is that I have not a single nit-pick today, but maybe this is just because everything in this PR is perfect? :)

I have very little context about meetings, if you want me to look for any tricky things in particular let me know.

Otherwise all good! 馃憤

@blackheaven
blackheaven merged commit 6d272aa into develop Jul 21, 2026
9 checks passed
@blackheaven
blackheaven deleted the gdifolco/WPB-26705-meeting-events-fix branch July 21, 2026 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants