fix(client): allow large sse events

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.

[harshmathurx]

Issue for this PR

Closes#36343

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A supported image read can emit a valid session.tool.success event larger than the generated Promise client's current 1 MiB SSE frame buffer. Because /api/event is global, one large event can disconnect every connected TUI subscriber with MalformedResponse, including TUIs displaying unrelated sessions.

Root cause: the generated client-side SSE parser enforces a fixed 1 MiB event buffer, but V2's supported media ingest path can legitimately produce encoded image events above that size.

This PR raises the generated Promise client's SSE frame buffer from 1 MiB to 32 MiB. That keeps a bounded limit for malformed/unbounded SSE frames while allowing supported large tool-success events to reach subscribers instead of disconnecting them.

@kitlangton, tagging you since you authored #36343 and the incident/repro. If the issue-link automation is still stale, could you link/clear the stuck needs:issue state on the PR?

How did you verify your code works?

• Added a Promise client regression test that streams a >1 MiB SSE event through event.subscribe.
• Ran bun test test/promise.test.ts from packages/client.
• Ran git diff --check.
• Attempted bun run generate from packages/client; blocked locally by dependency resolution: Cannot find module '@effect/platform/Cookies' from @effect/platform-node.
• Attempted bun test test/generate.test.ts from packages/httpapi-codegen; blocked locally because this worktree has no installed effect package.
• Automated PR checks currently pass, including check-standards and check-compliance; the needs:issue label appears stale even though this body has Closes #36343 in the required issue section.

Risk / reviewer notes

Focused client tolerance change. The limit remains finite, so this does not make malformed or unbounded SSE frames unlimited; it only moves the ceiling above the known valid image-event payload size from #36343. It does not change server event emission or subscription semantics.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally where possible
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found one potentially related PR:

PR #33289: fix(app): prevent web client freeze from delta event bursts and SSE reconnect loops
#33289

This PR addresses SSE-related issues with event handling and reconnect loops, which could be tangentially related to the buffer size issue being fixed in PR #36368. However, it appears to be focused on a different aspect (preventing freezes and reconnect loops) rather than directly addressing the buffer size limitation for large SSE events.

The current PR (#36368) is specifically about raising the SSE frame buffer from 1 MiB to 32 MiB to support large tool success events. This appears to be a targeted fix distinct from the reconnect loop handling in #33289.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[harshmathurx]

Hi @kitlangton — pinging for a review on this PR. It references #36343 and the automated checks are passing, but the "needs:issue" label appears stuck because the GitHub-linked issue is not showing up in the sidebar. Could you confirm the issue is linked (or manually link it) and take a look when you have a moment? Thanks!

[harshmathurx]

@kitlangton quick maintainer ping here as well. This is a focused fix for large SSE events, tied to #36343, and the checks are green. If the implementation direction looks acceptable, would appreciate a review when you can. If you want the issue linkage handled differently on your side, happy to adjust.

[harshmathurx]

Closing this to keep my OSS queue focused. This has stayed blocked on the repo's issue-link/triage process despite the linked issue and passing automated checks, and I don't want to add more maintainer noise. Happy to reopen or rework if a maintainer wants to pick it back up.