Sentry.captureException called in tight loop exhausted file handles

[dougforster-at]

• [x] Review the documentation: https://docs.sentry.io/
• [x] Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• [x] Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• [n/a] Provide a link to the affected event from your Sentry account

Package + Version

• [ ] @sentry/browser
• [x] @sentry/node
• [ ] raven-js
• [ ] raven-node (raven for node)
• [ ] other:

Version:

6.15.0

Description

We encountered a problem where:

1. exceptions were thrown
2. we caught them in a try/catch
3. we called Sentry.captureException(err, sentryContext);
4. this took place in a tight loop where many many exceptions were throw, caught and logged to Sentry

Result: the linux instance ran out file handles

We pinpointed https://github.com/getsentry/sentry-javascript/blob/8cbcff25235b8d67043820032dba7a9e9cae3a2a/packages/node/src/parsers.ts#L139 as the code that was opening the file handles.

We're interested to advocate for adding caching or enforcing a maximum number of open files, to avoid the risk of exhausting file handles on the host machine.

Thanks!

[AbhiPrasad]

Hey thanks for writing in!

We use an LRU cache to ensure that we cache calls to readFile, so it's interesting to see that this still happens.

https://github.com/getsentry/sentry-javascript/blob/8cbcff25235b8d67043820032dba7a9e9cae3a2a/packages/node/src/parsers.ts#L10

Perhaps we can add an additional check after the cache is full to check the file descriptor count.

Could you provide a link to your Sentry event or a copy of the event JSON (really we just need the exception object). That will help us start debugging and reproduce a test case!