Skip to content

feat: Return the real send result for renderer sendFeedback - #1433

Open
timfish wants to merge 3 commits into
masterfrom
feat/feedback-send-status
Open

timfish wants to merge 3 commits into
masterfrom
feat/feedback-send-status

Conversation

@timfish

@timfish timfish commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator

Fixes #1428

sendFeedback in a renderer resolved as soon as the envelope was handed to the main process, before anything was sent. In protocol mode the fetch was not even awaited, so closing the window straight after could abort the upload. This is a problem for apps that show "thanks for your feedback" on resolve, because the feedback can still be lost, for example behind a proxy that blocks requests to Sentry.

Feedback envelopes now go over their own IPC channel (ipcRenderer.invoke with a preload, an awaited fetch over the custom protocol). The main process prepares the event with prepareEvent, sends it with client.sendEnvelope and replies with the transport result. The renderer transport returns that result, so sendFeedback resolves on a 2xx and rejects on anything else, including a send that was queued offline, rate limited, dropped by an event processor, or not sent because main has enabled: false. This matches how sendFeedback behaves in the browser SDK with the offline transport.

captureEvent is not used for feedback because it doesn't expose the send result. Nothing is lost by that: beforeSend and sampleRate only apply to error events, and the hooks captureEvent emits have no listeners for feedback events.

All other envelopes are unchanged. They still return 200 immediately, so nothing else waits on the network.

The User Feedback e2e test now closes the window once sendFeedback resolves and asserts on the resolve. Unit tests cover the transport's channel choice.

sendFeedback resolved as soon as the envelope was handed to the main
process, before anything was sent. Feedback envelopes now go over their
own IPC channel. The main process prepares and sends them directly and
replies with the transport result, so sendFeedback resolves on a 2xx
and rejects when the send failed, was queued offline or was dropped.
Other envelopes are unchanged.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 5fa6a89. Configure here.

Comment thread src/renderer/transport.ts
Comment thread src/main/ipc.ts Outdated
Comment thread src/common/ipc.ts
Other event types must go through captureEvent so beforeSend and
sampleRate apply. A thrown error left the protocol response empty on
older Electron, which the renderer could not parse.
@timfish
timfish requested review from JPeer264 and msonnb September 17, 2026 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Renderer sendFeedback resolves even when Sentry never receives the event

2 participants