SDK
JavaScript SDK
Description
We’re David Vladuca and Alexandru Popa, two final-year Computer Science and Engineering bachelor’s students at TU Delft, contacting Sentry independently. After we shared this idea with Sentry Support, we were directed to open an issue in getsentry/sentry-docs so the documentation team could assess it.
We are exploring an interactive source-map failure investigation lab: a self-contained documentation/workshop companion in which a learner deliberately breaks one source-map condition, observes the resulting stack trace and diagnostic evidence, and works backward to the cause.
Sentry already documents source-map troubleshooting and exposes detailed event-level source-map diagnostics. The proposed lab would not replace those resources or sentry-cli. Its purpose would be to teach the causal reasoning behind them through controlled success/failure comparisons.
The initial scenarios would cover missing or mismatched debug IDs, artifact upload occurring after the test event, incorrect release association, and source-file or path mismatch.
Relevant public references:
Suggested Solution
The first version would use a small synthetic JavaScript application and a student-owned Sentry test project. It would:
- build and serve a production bundle;
- upload source-map artifacts using public Sentry tooling;
- trigger a deterministic test error;
- show the resulting symbolicated or unsymbolicated frame alongside relevant diagnostic evidence; and
- guide the learner through identifying and correcting the seeded mistake.
We would start with one polished working case and two failure modes, then expand only if the format is useful. The full MVP would be scoped to roughly 8–10 weeks part-time, built from public documentation, public APIs/tooling, and synthetic data. It would require no access to Sentry’s internal systems, and we would take responsibility for implementation.
Would this be useful as a workshop or documentation companion? If so, we would appreciate guidance on the most valuable first failure modes and the appropriate documentation location or format. We can first prepare a small prototype for review and would only need occasional feedback.
Thank you,
David Vladuca and Alexandru Popa
david.i.vladuca@gmail.com
SDK
JavaScript SDK
Description
We’re David Vladuca and Alexandru Popa, two final-year Computer Science and Engineering bachelor’s students at TU Delft, contacting Sentry independently. After we shared this idea with Sentry Support, we were directed to open an issue in getsentry/sentry-docs so the documentation team could assess it.
We are exploring an interactive source-map failure investigation lab: a self-contained documentation/workshop companion in which a learner deliberately breaks one source-map condition, observes the resulting stack trace and diagnostic evidence, and works backward to the cause.
Sentry already documents source-map troubleshooting and exposes detailed event-level source-map diagnostics. The proposed lab would not replace those resources or sentry-cli. Its purpose would be to teach the causal reasoning behind them through controlled success/failure comparisons.
The initial scenarios would cover missing or mismatched debug IDs, artifact upload occurring after the test event, incorrect release association, and source-file or path mismatch.
Relevant public references:
Suggested Solution
The first version would use a small synthetic JavaScript application and a student-owned Sentry test project. It would:
We would start with one polished working case and two failure modes, then expand only if the format is useful. The full MVP would be scoped to roughly 8–10 weeks part-time, built from public documentation, public APIs/tooling, and synthetic data. It would require no access to Sentry’s internal systems, and we would take responsibility for implementation.
Would this be useful as a workshop or documentation companion? If so, we would appreciate guidance on the most valuable first failure modes and the appropriate documentation location or format. We can first prepare a small prototype for review and would only need occasional feedback.
Thank you,
David Vladuca and Alexandru Popa
david.i.vladuca@gmail.com