feat(core): Allow delayed sending with offline transport

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.

[timfish]

• ClosesAllow postponing event captures until User Consent is collected #6758

This PR adds a extra callback to the offline transport that allows delaying sending of envelopes. This callback has existed in the Electron offline transport for a couple of major versions.

[AbhiPrasad]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

throwing an error seems strange, shouldn't we just do an early return?

[timfish]

Doesn't this mean that shouldQueue still can trigger from this? Wouldn't that lead to an infinite loop?

No because shouldQueue doesn't result in immediate sending, it backs off starting from a 5 second delay.

throwing an error seems strange, shouldn't we just do an early return?

Sorry, I should have explained that further!

We can't use an early return here without making breaking changes or duplicating a lot of code. If shouldSend returns false, we want to hit shouldQueue and that is currently in the catch block and the easiest way to end up in the catch block is to throw:

sentry-javascript/packages/core/src/transports/offline.ts

Lines 141 to 166 in c4dcdaa

	try{
	if(options.shouldSend&&(awaitoptions.shouldSend(envelope))===false){
	thrownewError('Envelope not sent because `shouldSend` callback returned false');
	}
	constresult=awaittransport.send(envelope);
	letdelay=MIN_DELAY;
	if(result){
	// If there's a retry-after header, use that as the next delay.
	if(result.headers?.['retry-after']){
	delay=parseRetryAfterHeader(result.headers['retry-after']);
	}elseif(result.headers?.['x-sentry-rate-limits']){
	delay=60_000;// 60 seconds
	}// If we have a server error, return now so we don't flush the queue.
	elseif((result.statusCode||0)>=400){
	returnresult;
	}
	}
	flushIn(delay);
	retryDelay=START_DELAY;
	returnresult;
	}catch(e){
	if(awaitshouldQueue(envelope,easError,retryDelay)){

Throwing errors for control flow isn't ideal but this PR also needs to replace this feature like-for-like in the Electron SDK so we don't need to make a breaking change there. This callback was implemented in the Electron SDK as a simple transport wrapper that throws when shouldSend returns true:

https://github.com/getsentry/sentry-electron/blob/6169e0ddea8d1fc7e9a75c8dfcc40e57d48b98d9/src/main/transports/electron-offline-net.ts#L22-L41

Implementing as per this PR means that in the Electron SDK we can just remove makeShouldSendTransport and the same behaviour will be retained.