Conversation
|
Will review this in a bit. In the mean time, getsentry/sentry-dotnet#280 is probably useful to read through. |
AbhiPrasad
left a comment
There was a problem hiding this comment.
Couldn't finish the review, but commenting what I have
|
I've got some more changes incoming because I have to correctly handle different statuses from the underlying transport.
|
|
Will finish reviewing this PR by eow, asked some other folks at Sentry to take a look to make sure we are not missing anything here. |
bruno-garcia
left a comment
There was a problem hiding this comment.
I didn't spot this piece in the PR but are the directories where the file dumps isolated per process instance? Is there a chance two instances would pick up anothers payloads?
Seems that the URL stored enodes the auth token (and project Id?) So even if they did, they'd just be uploading the dumps from another process, is that right?
Electron doesn't support multiple instances using the same |
Closes #369
BaseUploaderso there's only a single queueStoreso it can parseDateobjectsPersistedRequestQueuewhich stores an array of queue item metadata in aStoreand request bodies in separate filesElectronOfflineNetTransportthat extends theElectronNetTransportand makes it the default transport.sendRequestfails, it pushes the failed request into the queue.Tests
Electron network emulation with
{ offline: true }doesn't appear to work from the main process and invalid URLs take too long to timeout for reliable tests. Instead we have special DSNs which the server responds differently to.Still to do:
PersistedRequestQueuewith overlappingadd/popPersistedRequestQueuesince it's difficult to test all its features via e2eOther
This PR also introduces caching for Electron binaries because we were getting 503 Egress exceeded errors.