Squashing an Accidental Node.js Fork Bomb with Sentry

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. ...

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

I'm currently building this project for another hackathon. Basically it's a weather app that checks meteorological APIs for different cities and then fires off background tasks to update usersdashboards whenever there is extreme weather happening in their area.

Bug Fix or Performance Improvement

I have a GitHub Action that runs an hourly script (weather-sync-orchestrator.ts) to sync all this weather data. But as I added more test users the CI runner started randomly timing out and crashing.

Turns out I accidentally built a fork bomb in Node.js. My script was using a recursive setTimeout setup to try and throttle the API requests. Every time it processed a user it fired off overlapping timers which ended up starving the Node.js event loop and eating all the memory until the runner died.

Code

Here is the exact fix and where I set up Sentry

• Fix: Resolve event loop starvation and fork bomb in the orchestrator https://github.com/Tahiram32/living-website-meteorological-engine/commit/800c244

• Feat: Add Sentry monitoring to orchestrator and frontend https://github.com/Tahiram32/living-website-meteorological-engine/commit/485e344

My Improvements

I completely removed the weird setTimeout mess. I replaced it with a much cleaner loop that just uses await new Promise**(r => setTimeout(r, ms))** to pause execution.

Now instead of flooding the queue with timers it properly pauses and respects my concurrency limits and API rate limits synchronously. The script runs super smooth now and the GitHub actions haven't crashed since.

Bonus: Sentry Seer AI Autofix in Action!

After setting up the React SDK I added a manual "Break the world" error button to test the frontend tracing. Sentry not only instantly caught the error and diagnosed it correctly, but the Sentry Bot (Seer AI) autonomously opened a Pull Request ( #1 ) on my GitHub repository to safely strip the test component out of Storefront.tsx before it could hit production. It literally cleaned up my testing code for me!

Best Use of Sentry

To figure out why the CI was crashing in the first place I hooked up the @sentry/node and @sentry/profiling-node SDKs right into my backend script.

The tools were a lifesaver here. By setting the profilesSampleRate to 1.0, I was able to actually visualize the CPU spiking and see the event loop getting starved right in the Sentry dashboard before the runner died. Once I saw that the bug was obvious. I also threw the React SDK into my frontend (main.tsx) so I can keep an eye on things moving forward.