Vouch please: how to become a contributor

[matt-aitken]

Want to contribute to Trigger.dev? Request a vouch by leaving a comment below before opening your first pull request. PRs from unvouched contributors are automatically closed.

Important: Because Trigger.dev is production infrastructure, every external change needs a security review and verification by our team. Your vouch request is extremely unlikely to be accepted unless you are already known to the Trigger.dev team in some way, either as a customer or self-hoster or some other reason we’d be familiar with your work.

We really appreciate bug reports or feature requests. A good reproduction always gets fixed faster than a PR would get merged. You can even suggest the architecture of the fix in the bug report under "Suggested fix".

Please include:

• What you’d like to work on, with a link to the issue if there is one.
• A little about your background, with links to relevant projects or previous contributions if available.

A maintainer will review your request and let you know once you’ve been added to the vouched contributors list. Please don’t open a separate issue or discussion to request a vouch.

Once approved, follow our contributing guidelines and open your PR as a draft first.

Being vouched lets you submit PRs; it does not guarantee that a particular change will be accepted.

[61465]

Hi — would like to request vouching so I can open a PR for an existing issue.

What I'd like to work on:
#4819 — batchTrigger returns stale failed runs as isCached: true instead of re-triggering when the idempotency key points to a dead run. The single-trigger path handles this correctly via shouldIdempotencyKeyBeCleared; the batch path at batchTriggerV3.server.ts:450 was missing the status check because PostgresRunStore.findRunsByIdempotencyKeys never selected the status column.

I already wrote the fix as a courtesy draft before realising the vouching workflow — PR #5014 (auto-closed by check-vouch). It's 4 files: adds status to the SQL + IdempotencyKeyRunMatch type, imports shouldIdempotencyKeyBeCleared into #prepareRunData, and adds a postgres regression test covering PENDING / CRASHED / COMPLETED_WITH_ERRORS / COMPLETED_SUCCESSFULLY. Full credit to the reporter @Jaimin2687 for the RCA. Happy to re-open as a draft once vouched, or to abandon it entirely if you'd prefer the fix to come from the team.

Background:

• Prior contribution to this repo: GHSA-65rr-73jq-6qhf — accepted by @crofty on 2026-10-07.
• Other recent OSS work: PostHog #5083 (merged), Supabase storage #1488 / #1499 / #1500, Supabase auth #2863.
• GitHub: @61465.

Thanks for considering.

[harshitsharmaaaa]

Hi Trigger.dev team,

I'm Harshit, a final-year CS student who works mostly in TypeScript and Node.js. I'd like to be vouched so I can start contributing to Trigger.dev, with a focus on task execution and observability. Two issues caught my eye, and I have a clear plan for each.

[#3672]: metrics lose run attribution after a waitpoint resume
taskContext.disable() runs at the waitpoint but is never reversed on resume, so TaskContextMetricExporter keeps stripping RUN_ID, TASK_SLUG and ATTEMPT_NUMBER. I'd first confirm why disable() is used there, then add a taskContext.enable() called where wait.for() returns to user code, with tests for resume, between-run stripping and multiple waitpoints.

[#4313]: trace IDs shared across concurrent cron runs
The startup-generated externalTraceId overwrites span trace IDs for every task. I'd apply it only when a real parent context was propagated, so each attempt otherwise becomes its own root trace, with tests for concurrent runs and unchanged propagation behavior.

For both, I'll confirm the approach with a maintainer before opening a PR.

My open source work:

• [commaai/connect #892](refactor: consolidate URL parsing and generation into routes.js (#770) commaai/connect#892): consolidated URL parsing and generation into a single routes.js module and expanded the routing tests
• [commaai/connect #911](fix: clarify file download segment scope (#638) commaai/connect#911): clarified the scope of file download actions, with regression tests
• [TraceRoot #2533](ci: pin GitHub Actions to commit SHAs traceroot-ai/traceroot#2533): pinned GitHub Actions to immutable commit SHAs
• [TraceRoot #2526](fix(alerts): correct undelivered notification badge text traceroot-ai/traceroot#2526): corrected alert badge messaging to match actual notification redelivery behavior
• [self-healing-hybrid-RAG #1](Feature/fix setup and robustness AmartyaRanjan/self-healing-hybrid-RAG#1) (merged): fixed a stale-state leak by resetting the BM25 index on each retrieval pass

GitHub: https://github.com/harshitsharmaaaa

Thanks,
Harshit

[Sadikdeveloper]

Hi Trigger.dev team,

I'd like to request a vouch so I can open a PR for #5017.

What I'd like to work on

eventFilterMatches returns false for a nested $exists: false filter when a parent key is missing or null. It early-returns false on a nullish payload before $exists is ever evaluated, so a retry.fetch bodyFilter like { error: { retryAfter: [{ $exists: false }] } } can't match a body with no error object. The fix is to evaluate the filter against an empty object when the payload is nullish, which makes nested behave like top-level.

I'd already prepared the fix before I saw the vouch requirement: PR #5022, which check-vouch auto-closed. It changes eventFilterMatches.ts, adds regression tests in core and in the SDK's retry.test.ts, and includes a @trigger.dev/core changeset. I can re-open it as a draft once vouched, or drop it and post the RCA and suggested fix on the issue instead, whichever you prefer.

About me

I'm Abubakar, a TypeScript developer (NestJS, Prisma, PostgreSQL, Redis, React, React Native) building Rown, a non-custodial crypto wallet. I'm planning to self-host Trigger.dev for businesses around me but haven't started yet. I came across this bug while looking at retry.fetch and bodyFilter.

GitHub: @Sadikdeveloper

Thanks for considering.

[techize]

Hi, I'd like to pick up #4951 (IRSA credentials fail because fast-xml-parser 5.7 rejects the entities xml-builder 3.930 registers).

We self-host trigger.dev on EKS for platform team jobs and ran into this moving the object store from MinIO to S3. I've got a branch that bumps the AWS SDK packages in the webapp, supervisor and emails to 3.1140.0, which only resolves the fixed xml-builder, and we've been running the equivalent patch on our UAT install. I'm an SRE, mostly Kubernetes, Terraform and Helm.

[61465]

Nudging on this since it's been 4 days and I noticed 3 other folks (@harshitsharmaaaa, @Sadikdeveloper, @techize) are also waiting — the backlog looks real. Not a complaint, just offering to help where I can:

Status of my original request

The PR for #4819 (batchTrigger returning stale CRASHED runs as isCached:true) is still ready — fix in #prepareRunData, 4 files, +95/-4, with a postgres regression test. Happy to re-draft once vouched, or close out if the team would rather fix it internally.

Quick note on fit, in case it's useful

Context on where I'm coming from, since the vouch gate was built partly for signal:

• Prior work in this repo: GHSA-65rr-73jq-6qhf accepted by @carderne on 2026-10-07 (CVSS 9.6, idempotency key cross-run leak).
• Elsewhere in the last ~45 days: 10 OSS orgs with public standing, 2 merged (supabase/storage#1500 by @ferhatelmas, PostHog/posthog-js#5083 by @marandaneto), 7 in review (Sentry Relay, SvelteKit, Drizzle ORM, Inngest, Supabase storage ×3, Supabase auth, PostHog), 3 maintainer-blessed design proposals (Prisma ORM v7, Node.js core v22/v24, Nitro v3). Full list on my profile.
• Stack overlap: TypeScript + Node + Postgres + idempotency + queueing is my daily driver. Also did the Documenso GHSA-2rp7-mrh6-v9m2 (CVSS 7.6, rejected-recipient forgery across 3 tRPC routes) in the same cycle.

Offer

If helpful: I'd happily help triage the other three waiting vouch requests on this thread. Any team member who sees this is welcome to point me at a shortlist, I can summarise each requester's prior work + proposed scope + risk, and you can approve/deny from a short writeup instead of three separate deep reads. Zero commitment on your side — just a time-saver.

And on the operational side: I saw the Backend Engineer (Security) and Senior Backend Engineer (Europe) roles on your careers page. I'd love to chat about the first one when you have bandwidth — abdarahman10555@gmail.com or wherever's easiest. In the meantime the vouch unlock stays the useful thing regardless of whether that conversation ever happens.

Thanks @crofty / @carderne / @ericallam — appreciate the time.

[ferhatelmas]

@61465 a correction, PR mentioned/merged on supabase/storage is supabase/storage#1500

[61465]

Oh! You are right - thanks @ferhatelmas. The bare #1500 auto-linked to a trigger.dev issue instead of yours. Just edited the comment to use the full supabase/storage#1500 reference. Appreciate the eye.

[mmadhavvvv]

Hi Trigger.dev team,

I'd like to request a vouch so I can start contributing to Trigger.dev.

What I'd like to work on

I'm interested in contributing to backend reliability, task execution, integrations, and developer tooling. I'm currently exploring the codebase and would like to identify a well-scoped issue where I can provide a reproducible bug report, investigate the root cause, and propose a tested fix.

I'm happy to discuss the approach with a maintainer before making any changes.

About me

I'm Madhav, a Computer Science Engineering graduate from Amity University, India. I've worked as a DevOps Engineer Intern, where my work involved AWS infrastructure, Terraform, CI/CD pipelines, infrastructure security, and monitoring.

I'm also building my application development experience with FastAPI, React, and PostgreSQL.

My GitHub: https://github.com/mmadhavvvv

One of my projects: https://github.com/mmadhavvvv/Maharaj-website

I'm looking forward to learning from the team and making useful, well-tested contributions to Trigger.dev.

Thank you for considering my request!