Skip to content

fix(events): fall back to the generic alert payload schema - #288

Open
acoyfellow wants to merge 1 commit into
cloudflare:mainfrom
acoyfellow:jcoeyman/events-schema-fallback
Open

acoyfellow wants to merge 1 commit into
cloudflare:mainfrom
acoyfellow:jcoeyman/events-schema-fallback

Conversation

@acoyfellow

Copy link
Copy Markdown
Contributor

alertEventDefinitions reads EventPayloadSchemas[alert.type] directly. If an alert type is added to SUPPORTED_ALERT_TYPES without its own schema, events/list throws:

TypeError: Cannot use 'in' operator to search for '_idmap' in undefined

Delivery already falls back to AlertPayload for the same case. This PR makes both paths use one function, payloadSchemaFor.

No behavior change today: workers_observability_real_time_issue is the only supported type, and it keeps its own schema. It makes adding the next alert type a one-line change.

Verified

  • Reproduced on main: with universal_ssl_event_type added to the supported set, alertEventDefinitions throws. On this branch it returns both events, each with an object payload schema.
  • New test: falls back to the generic alert payload for types without their own schema.
  • npm test: 483 passed. npm run test:events: 71 passed. tsc --noEmit, oxfmt --check and oxlint pass (the one lint warning is already on main).

alertEventDefinitions read EventPayloadSchemas directly, so adding an alert
type to SUPPORTED_ALERT_TYPES without its own schema made events/list throw.
Use the same AlertPayload fallback that delivery already uses.
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