Fix: Move receive() outside loop to fix stream consumption by dcherrera · Pull Request #170 · modelcontextprotocol/swift-sdk

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

dcherrera · 2025-11-04T04:19:08Z

Summary

The Client was calling connection.receive() inside a repeat { } while true loop, which meant it was trying to iterate the same async stream multiple times. Async streams can only be iterated once.

This fix:

Moves receive() outside the loop so the stream is obtained once
Removes the repeat { } while true wrapper (no longer needed)
Removes EAGAIN handling (was only needed due to the repeat loop)

This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

Before (Bug)

repeat{letstream=await connection.receive() // ❌ Called on each iteration
fortryawaitdatain stream {...}}whiletrue

After (Fix)

letstream=await connection.receive() // ✅ Called once
fortryawaitdatain stream {...}

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling

DePasqualeOrg · 2026-01-04T20:27:39Z

Thanks for your contribution, @dcherrera. My PR #175 addresses the same root cause, with some differences in implementation. If you think I've missed something, or if you have any feedback on my PR, please let me know.

The key difference in my PR is that I remove the outer repeat { } while true loop entirely rather than adding timeouts/sleeps to mitigate the spinning. This aligns with how the TypeScript and Python SDKs handle receive loops (single stream iteration, no retry loop).

My PR also removes the EAGAIN handling at the client layer (transports handle this internally) and adds pending request cleanup on unexpected disconnect.

Async streams can only be iterated once. The previous implementation called connection.receive() inside a repeat loop, which attempted to create a new stream on each iteration from an already-consumed stream. This fix: - Moves receive() outside the loop so the stream is obtained once - Removes the repeat { } while true wrapper (no longer needed) - Removes EAGAIN handling (was only needed due to the repeat loop) This aligns with how the TypeScript and Python SDKs handle the receive loop (single stream iteration, no retry loop).

dcherrera · 2026-01-04T20:54:50Z

I've simplified this PR to a minimal, focused fix that addresses only the core bug.

Changes from the previous version:

Removed all debug logging (NSLog statements)
Removed the Task.sleep workaround
Removed the timeout wrapper additions to send()
Kept only the essential fix: moving receive() outside the loop

Why keep this PR open?

While #175 also fixes this issue, it's a massive PR (50+ files, new protocol versions, HTTP server support, etc.) that may take time to review and merge. This PR provides a minimal fix that could be merged quickly as a stopgap if needed.

Happy to close this if the maintainers prefer to wait for #175.

DePasqualeOrg · 2026-01-04T21:51:55Z

Keep in mind that you still need to clean up pending requests on unexpected disconnect, which I do in my defer block. If this gets merged first, I'll just rebase and resolve the conflict if the maintainers decide to review my PR.

dcherrera · 2026-01-05T18:33:36Z

I don't have time to deal with people like you. I submitted the fix for my use case. They either want it or don't. I don't need to pad my resume. i already got paid.

DePasqualeOrg · 2026-01-05T18:42:15Z

@dcherrera, you're turning an issue of code correctness into a personal attack.

dcherrera · 2026-01-05T19:03:55Z

Ok have a good day

toasterbook88 · 2026-02-24T01:56:04Z

Maintainer triage on February 24, 2026: recommended close for backlog hygiene. This stale PR conflicts with main and similar client-path work has continued in newer changes; reopen a rebased PR if remaining fixes are still needed.

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

DePasqualeOrg mentioned this pull request Jan 4, 2026
Add functionality for MCP versions 2025-06-18 and 2025-11-25 #175
Closed
5 tasks

dcherrera force-pushed the fix/process-transport-actor-isolation branch from 4e906a6 to fe4dda0Compare January 4, 2026 20:52

dcherrera changed the title ~~Fix: Move receive() outside repeat loop to fix stream consumption~~Fix: Move receive() outside loop to fix stream consumptionJan 4, 2026

dcherrera closed this Apr 17, 2026

dcherrera deleted the fix/process-transport-actor-isolation branch April 17, 2026 07:29

Uh oh!

Conversation

dcherrera commented Nov 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Before (Bug)

After (Fix)

Related

Types of changes

Checklist

Uh oh!

DePasqualeOrg commented Jan 4, 2026

Uh oh!

dcherrera commented Jan 4, 2026

Uh oh!

DePasqualeOrg commented Jan 4, 2026

Uh oh!

dcherrera commented Jan 5, 2026

Uh oh!

DePasqualeOrg commented Jan 5, 2026

Uh oh!

dcherrera commented Jan 5, 2026

Uh oh!

toasterbook88 commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

dcherrera commented Nov 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Before (Bug)

After (Fix)

Related

Types of changes

Checklist

Uh oh!

DePasqualeOrg commented Jan 4, 2026

Uh oh!

dcherrera commented Jan 4, 2026

Uh oh!

DePasqualeOrg commented Jan 4, 2026

Uh oh!

dcherrera commented Jan 5, 2026

Uh oh!

DePasqualeOrg commented Jan 5, 2026

Uh oh!

dcherrera commented Jan 5, 2026

Uh oh!

toasterbook88 commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

dcherrera commented Nov 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Before (Bug)

After (Fix)

Related

Types of changes

Checklist

Uh oh!

DePasqualeOrg commented Jan 4, 2026

Uh oh!

dcherrera commented Jan 4, 2026

dcherrera commented Nov 4, 2025•
edited
Loading

dcherrera commented Nov 4, 2025•
edited
Loading

dcherrera commented Nov 4, 2025•
edited
Loading

dcherrera commented Nov 4, 2025•
edited
Loading