Skip to content

Conversation

@aryan-25
Copy link
Collaborator

@aryan-25 aryan-25 commented Jan 9, 2026

Motivation:

Currently, we do not use the maximumCount argument in HTTPRequestConcludingAsyncReader's read(maximumCount:body:) method.

Modifications:

Updated HTTPRequestConcludingAsyncReader/read(maximumCount:body:) to throw a LimitExceeded error when the bytes available exceed maximumCount.

Result:

The maximumCount argument is now respected in HTTPRequestConcludingAsyncReader/read(maximumCount:body:).

@Lukasa Lukasa added the 🔨 semver/patch No public API change. label Jan 9, 2026
Comment on lines +80 to +82
if let maximumCount, maximumCount < element.readableBytes {
throw .first(LimitExceeded())
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm actually unsure about this. I wonder if we should only return maximumCount bytes and keep the rest of the bytes in a local buffer until the next read call, or if we should throw. The only way to get out of this throwing scenario is by increasing the count, which sounds potentially problematic.

//===----------------------------------------------------------------------===//

/// Data available in a read buffer exceeded the caller-specified maximum count.
struct LimitExceeded: Error {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure we need this based on the other comment but if we do, I think it makes more sense to have a namespace for this, either by nesting it inside the HTTPRequestConcludingAsyncReader or by having some other error namespace and nesting it there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔨 semver/patch No public API change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants