Skip to content

Add room-scoped webhook configuration - #1

Open
Darshak03 wants to merge 1 commit into
mainfrom
room-webhooks
Open

Add room-scoped webhook configuration#1
Darshak03 wants to merge 1 commit into
mainfrom
room-webhooks

Conversation

@Darshak03

Copy link
Copy Markdown
Owner

Summary

Rooms can currently only be observed through the globally configured webhook URLs — there is no way to send one room's events to its own endpoint. This adds that, following the shape egress already uses for per-resource webhooks.

Branched off a4f4b5c (the commit livekit-server currently pins), so the diff is just this change.

How egress does it today

  1. repeated WebhookConfig webhooks sits on the request proto (StartEgressRequest, RoomCompositeEgressRequest, …).
  2. The request is embedded in the long-lived resource state (EgressInfo.Request), so the config is available at every event, not just the one that created the resource.
  3. egress/notify_options.go derives []webhook.NotifyOption from that state.
  4. The emit site spreads opts... into QueueNotify.

The room analogue

egress room
RoomCompositeEgressRequest.webhooks CreateRoomRequest.webhooks (field 16)
RoomConfiguration.webhooks (field 13), for named presets
EgressInfo.Request RoomInternal.webhooks (field 9)
egress.GetEgressNotifyOptions webhook.GetRoomNotifyOptions

RoomInternal is the right carrier: it is server-side state that already persists with the room, exactly like EgressInfo.Request. The public Room proto deliberately does not get the field — entries hold signing keys and Room is returned by ListRooms.

The helper lives in webhook rather than a new room package: the event constants are already there, and a package named room collides with the ubiquitous room variable at the call sites in the server.

Event scope

Only room, participant and track events reach a room webhook — room_started, room_finished, participant_joined, participant_left, participant_connection_aborted, track_published, track_unpublished.

Egress, ingress and agent events are excluded by an allowlist. Those resources carry their own webhook config on the request that created them, so forwarding them to a room webhook would both duplicate delivery and leak beyond the room's scope.

No new delivery machinery

DefaultNotifier.QueueNotify already fans out to the static config URLs first and then to each extra webhook, resolving SigningKey through the KeyProvider and honouring per-webhook FilterParams. This change only supplies the option.

Codegen

Regenerated with the full twirp batch from magefile.go so livekit_room.twirp.go keeps its twirpFileDescriptor5 slot. Files whose only diff was the protoc version string were reverted, so the diff is limited to the three files that actually changed.

Tests

webhook/room_notify_options_test.go — every room-level event produces the option and round-trips the webhook list through NotifyParams; every egress/ingress/agent event produces nil; a room with no webhooks produces nil.

The consuming server-side change is a separate PR.

Rooms can currently only be observed through the globally configured
webhook URLs. Egress already supports per-resource webhooks by carrying a
`repeated WebhookConfig webhooks` on the request that created it and
deriving notify options from it at emit time; this applies the same shape
to rooms.

- CreateRoomRequest.webhooks lets an API caller attach webhooks to a
  single room, and RoomConfiguration.webhooks does the same for a named
  room preset.
- RoomInternal.webhooks persists the resolved list. It is the analogue of
  EgressInfo.Request: server-side state that travels with the resource.
  The public Room proto deliberately does not carry it, since entries hold
  signing keys and Room is returned by ListRooms.
- webhook.GetRoomNotifyOptions mirrors egress.GetEgressNotifyOptions,
  turning a room's webhook list into a WithExtraWebhooks option. It lives
  in the webhook package rather than a new one because the event
  constants are already there and a `room` package would collide with the
  ubiquitous `room` variable at the call sites.

Only room, participant and track events are delivered to room webhooks.
Egress, ingress and agent events are excluded by an allowlist: those
resources carry their own webhook config, so forwarding them here would
both duplicate delivery and leak beyond the room's scope.

No new delivery machinery is needed. DefaultNotifier.QueueNotify already
fans out to the static URLs first and then to each extra webhook,
resolving SigningKey through the KeyProvider and honouring per-webhook
FilterParams.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant