Fix event stream line parsing to handle CRLF and empty lines correctly

[aspitz]

Optimized code in connectToEventStream to use .lines computed value of AsyncSequence to produce a AsyncLineSequence instead of building a lines manually.

Motivation and Context

How Has This Been Tested?

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Optimization

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
• I have added or updated documentation as needed

Additional context

[mattt]

Nice! That sounds like a totally reasonable optimization. Thanks so much for sharing it.

I kicked off a CI build. Should get a chance to review it in depth over the weekend.

[stallent]

I def like the code change but checked out the branch and tested and it doesn't seem to be detecting the empty line that the code needs to dispatch notifications. I can only assume it works for you but for me line 225 is never catching so the client isn't getting the notes, where it did before going byte at a time.

[aspitz]

Apologies, I jumped the gun in submitting this PR.

The core issue I experienced was that line 229 while let newlineIndex = buffer.firstIndex(of: "\n") { doesn't appear to handle "\r\n" as a separate carriage return followed by a newline so it returns a nil instead of an index.

I've updated the code to while let newlineIndex = buffer.utf8.firstIndex(where: { $0 == 10 }) which handles "\r\n" properly and I've added a unit test to test for the "\r\n" scenario. I've added code to trim carriage returns at the end of the line. Between that and the fact that creating line trims newline of the end of the line the end of event test becomes much simpler.

[stallent]

@aspitz Thank you! Yeah, its annoying and we have run into that before. We have MCP servers running in python that return different line endings than the ones we have running in node+typescript, CRLF vs CRLF+CRLF.

[mattt]

@aspitz @stallent Good morning! Thank you both for looking into this. I started to write a reply, but waited too long and y'all beat me to it.

To @stallent's point, I found this post on the Apple Developer forums from someone running into the same problem using .lines for SSE parsing.

Taking a fresh look at this now 😄

[stallent]

@mattt if you take this, i'll resolve any merge conflicts with my minimal fix to get streamable htttp client working with latest servers. Still think we have larger api chats around that, but hopefully the modest current PR (vs the too big of one i was pursuing) will unblock us until further chats can be had.

[mattt]

This is looking good. Thank you again, @aspitz, for your work on this. I just updated the PR to reflect the final changes, and will merge this shortly.