Vouch request: volodymyrshk — #3781 source-map / Sentry compatibility #4967

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