fix: send responseReceived with EventSource type for SSE requests

[BAIXIONGSODA]

PR: Fix SSE (Server-Sent Events) DevTools Display

Summary

This PR fixes the SSE request display in Chrome DevTools Network panel by sending Network.responseReceived with type: EventSource before streaming SSE messages.

Changes

packages/network-debugger/src/core/fetch.ts

• Add loadCallFrames() call to capture initiator stack trace for fetch requests
• Send eventSourceResponseReceived message to properly notify DevTools about SSE responses

packages/network-debugger/src/fork/module/network/index.ts

• Add new handler eventSourceResponseReceived to send Network.responseReceived with type: EventSource
• This ensures DevTools correctly identifies and displays SSE requests

Why

Previously, SSE requests were not properly displayed in DevTools because the responseReceived event was not sent with the correct type: EventSource. This fix ensures:

1. SSE requests show up correctly in the Network panel
2. The request type is properly identified as EventSource
3. Initiator stack trace is captured for better debugging

Testing

Tested with koa-esm app's /sse-fetch endpoint - SSE events are now properly captured and displayed in DevTools.

[BAIXIONGSODA]

The original mainProcess.sendRequest('updateRequest', requestDetail) only syncs the request data to the fork process cache (requests[request.id] = request) — it doesn't send any CDP message to DevTools, so it had no visible effect at that point in the SSE flow.

The new eventSourceResponseReceived handler already does the same cache update internally (line 203: requests[request.id] = request), and additionally sends Network.responseReceived with type: 'EventSource' to DevTools — which is exactly what's needed for DevTools to correctly identify and display the SSE connection.

So the two calls are not equivalent: the original updateRequest was effectively a no-op here (the cache gets properly updated again in the finally block via endRequest), while eventSourceResponseReceived replaces it with the meaningful behavior. Adding updateRequest back would just be a redundant double cache write with no additional benefit.

As for the original fetch behavior — this change is scoped entirely within handleEventStreamResponse, which is only entered when the response Content-Type is text/event-stream. All regular (non-SSE) fetch requests go through the existing fetchResponseHandlerFactory path, which is completely untouched.

[GrinZero]

It's nice that you're willing to keep optimizing.

[GrinZero]

I added you to [Collaborators], after which you can submit directly on the repository~

[BAIXIONGSODA]

I added you to [Collaborators], after which you can submit directly on the repository~

I'm glad I could help. I've accepted the invitation.