I think the Node integration tests are failing because this change introduces an async event processor and this in turn causes the session/event envelopes to be received in a different order.

The async OS evaluation needs to handle reentrancy properly.

If a second events occurs before the async task has completed, _cachedContexts will be defined but not fully populated. _cachedContexts should therefore be a Promise which is awaited every time.

Now only the dynamic properties are calculated on every event and everything else is cached.

We don't call _getContexts() from the constructor because on some platforms this will cause it to read files and spawn processes immediately, even if an event is never sent.

Hey Tim, any updates on this? Any help you need from our side to investigate or look into stuff?

Hopefully #5579 will unblock the test failures for this PR.

With #5579 getting merged in, we can rebase this and see if that helps with the test failures!

Do we have to revert some of the previous test fixes?

@timfish, I'm working on it. 👍

Alright #5596 has been merged in! We can try rebasing and trying again here!

I've been away for a few days but will get back onto this on Monday!

Tests are all passing 🎉🎉🎉🎉🎉

Thanks @onurtemizkan for all your hard work fixing this for me!

I see there are some new methods for fetching single events. Is it a better idea to use those over my new filtering method?

I see there are some new methods for fetching single events. Is it a better idea to use those over my new filtering method?

Moving filters inside the nock interceptors helped keep the required event / transaction count by type, so we don't need to jump indices anymore. There were old flaky test cases that were jumping indices by 3 and that was hard to write / debug.

Alright, so I think once we swap filterEnvelopeItems for the new methods, we should be good to merge this!

All done! I also replaced getMultipleEnvelopeRequest with getEnvelopeRequest where appropriate.

Thanks so much for your patience @timfish - and thanks @onurtemizkan for the fixes!!!

has this been tested on serverless environments? like azure functions?

stacktrace:

RangeError: Invalid time value
  ?, in Date.toISOString
  File "C:\home\site\wwwroot\node_modules\@sentry\node\cjs\integrations\context.js", line 177, col 64, in getDeviceContext
  File "C:\home\site\wwwroot\node_modules\@sentry\node\cjs\integrations\context.js", line 95, col 25, in Context._getContexts
  File "C:\home\site\wwwroot\node_modules\@sentry\node\cjs\integrations\context.js", line 51, col 46, in Context.addContext

Hey @Venipa could you open a new issue re: your problem? Would be great to get a) your node version, b) the JS runtime that azure functions uses

It would be that process.uptime is causing problems.