Why do you want to contribute?
I'd like to work on #3781, where the managed run worker's source-map-support stack rewriting can interfere with Sentry's own source-map symbolication when users upload source maps.
I've been reading through the issue and the worker/runtime path. What interests me is finding a fix that preserves Trigger.dev's own readable stack traces without breaking external error-reporting tools that depend on the original bundled frames / debug IDs.
I'd keep the contribution scoped to #3781 and add focused regression coverage. My first direction would be to make the runtime stack rewriting opt-out/configurable for deployments that rely on external source-map symbolication, but because this touches a shared runtime/error-reporting path, I'd rather follow the maintainers' preferred boundary before coding too far ahead.
This would be my first contribution to Trigger.dev.
Prior contributions or relevant experience
I'm a backend/full-stack TypeScript and Node.js developer. Most of my work has involved external APIs and integrations, webhooks, auth, retries/idempotency, production debugging, and reliability work across Node.js/TypeScript services.
I've also worked with React/Next.js, PostgreSQL, Docker, Linux, and cloud deployments, so I'm comfortable tracing issues across application and runtime boundaries and adding focused regression tests.
GitHub: https://github.com/volodymyrshk
Why do you want to contribute?
I'd like to work on #3781, where the managed run worker's
source-map-supportstack rewriting can interfere with Sentry's own source-map symbolication when users upload source maps.I've been reading through the issue and the worker/runtime path. What interests me is finding a fix that preserves Trigger.dev's own readable stack traces without breaking external error-reporting tools that depend on the original bundled frames / debug IDs.
I'd keep the contribution scoped to #3781 and add focused regression coverage. My first direction would be to make the runtime stack rewriting opt-out/configurable for deployments that rely on external source-map symbolication, but because this touches a shared runtime/error-reporting path, I'd rather follow the maintainers' preferred boundary before coding too far ahead.
This would be my first contribution to Trigger.dev.
Prior contributions or relevant experience
I'm a backend/full-stack TypeScript and Node.js developer. Most of my work has involved external APIs and integrations, webhooks, auth, retries/idempotency, production debugging, and reliability work across Node.js/TypeScript services.
I've also worked with React/Next.js, PostgreSQL, Docker, Linux, and cloud deployments, so I'm comfortable tracing issues across application and runtime boundaries and adding focused regression tests.
GitHub: https://github.com/volodymyrshk