Uh oh!
There was an error while loading. Please reload this page.
feat(worker/tasks): ✨ Handle MEMBER_ADD and MEMBER_REMOVE webhooks - #139
Merged
Conversation
The roadmap lists both as BuildTeam webhook events, but the task only knew the application and claim types, so a member event was logged as unknown and dropped. api-v2 dispatches them once its member routes land. The payload is projected rather than passed through: the default branch forwards whatever it is given, and a user row carries the ssoId of the Keycloak account behind the person, which is not a BuildTeam's business. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kyanvde added a commit
that referenced
this pull request
Aug 28, 2026
The worker learns both event types in #139, so adding and removing a member now reaches the team's own webhook as well as Discord and the website revalidation. The payload is listed field by field rather than spread: a member is selected with ssoId on it, which is the Keycloak account behind the person and has no business leaving this service, and a test now holds that line. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nudelsuppe42
approved these changes
Aug 29, 2026
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Teaches the BuildTeam webhook task the two member events the roadmap already lists.
AuditLogBuildTeamTypeonly knew the application and claim types, so aMEMBER_ADDorMEMBER_REMOVEjob was logged as an unknown type and dropped. api-v2's member routes (#138) dispatch both once they land, so this has to be in place first — it is deliberately a separate PR againstmain, becauseapps/workerdoes not exist on the long-livedapi/v2branch.The payload is projected, not passed through.
transformData's default branch forwards whatever it is handed — its own comment says it strips nothing — and the natural payload for a member event is a user row, which carriesssoId: the Keycloak account behind the person. A build team has no business receiving that, so the member case selectsid,username,discordId,minecraft,avatarandbuildTeamIdexplicitly, matching what the application case already forwards about a user.No behaviour changes for any existing event type; the diff is one enum extended and one
switchcase added.Testing
yarn ws worker buildpasses.apps/worker/test/index.test.tsis a manual trigger script rather than a suite, so there was nothing to extend; the task itself is unchanged apart from the new case.🤖 Generated with Claude Code