v1.0.30: Closing the Gap on OrgInviteSentData Type Safety

Release 1.0.30 is a focused, non-breaking housekeeping fix that brings the TypeScript interface for the organisation-invite Inngest event into alignment with the data that is actually dispatched and consumed at runtime.

Background

Our invite flow uses Inngest to decouple the act of creating an invite from the act of sending the invite email. When a user is invited to an organisation, the invite router (src/lib/routers/invite.ts) fires an OrgInviteSent event. The inviteEmail Inngest function (src/inngest/functions/invite-email.ts) listens for that event and uses the payload to construct and dispatch the email.

The Problem

Two fields were present in the live event payload but were absent from the OrgInviteSentData TypeScript interface:

Field	Sent by invite.ts	Declared in OrgInviteSentData
inviteId	✅ Yes	❌ No (mentioned only in a comment)
invitedByName	✅ Yes (string | null)	❌ No

Because neither field was typed, TypeScript could not catch any future misuse — such as a typo in the field name, an incorrect type assumption, or a refactor that silently dropped a field.

Note: This was not a runtime bug. Both fields were being sent and were available to the function at runtime. The gap existed only at the type level.

The Fix

The OrgInviteSentData interface in src/inngest/events.ts now declares both fields explicitly:

export interface OrgInviteSentData {
  // ...existing fields...
  inviteId: string;
  invitedByName: string | null;
}

This single change ensures that:

1. The interface is the single source of truth for what an OrgInviteSent event carries.
2. TypeScript will catch mismatches between what the router sends and what the function expects, at compile time rather than at runtime.
3. Future contributors can rely on the type definitions rather than cross-referencing comments or reading the dispatch callsite.

Impact

• No changes to runtime behaviour.
• No database migrations required.
• No API changes.
• Safe to deploy as a standard release.