Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make StreameRequest.sink a StreamSink #965

Merged
merged 7 commits into from
Jun 20, 2023
Merged

Make StreameRequest.sink a StreamSink #965

merged 7 commits into from
Jun 20, 2023

Conversation

natebosch
Copy link
Member

Closes #727

This class was not designed for extension, but there is at least one
extending implementation. I don't see any overrides of this field, so no
existing usage should be broken.

Closes #727

This class was not designed for extension, but there is at least one
extending implementation. I don't see any overrides of this field, so no
existing usage should be broken.
@natebosch
Copy link
Member Author

Ah interesting, this causes new unwaited_futures diagnostics to show up because close() now returns a Future. Those did not impact the package roll internally, and I think we can still treat it as not breaking for the ecosystem, even if it could cause some CI failures.

@brianquinlan
Copy link
Collaborator

Closes #727

This class was not designed for extension, but there is at least one extending implementation. I don't see any overrides of this field, so no existing usage should be broken.

Yeah, this change is technically breaking. If we assume that it is non-breaking because no one implements this class then you could change it to base at the same time (I think).

..sink.add('{"hello": "world"}'.codeUnits)
..sink.close();
request.sink.add('{"hello": "world"}'.codeUnits);
await request.sink.close();
Copy link
Collaborator

Choose a reason for hiding this comment

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

None of the awaits in the tests are necessary, right? Otherwise this would be a breaking change.

Copy link
Member Author

Choose a reason for hiding this comment

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

Only necessary for lints - although it looks like adding the await can be breaking, so we may want to reconsider the risk of this change. It would be safe to use unawaited() exclusively instead.

@@ -32,7 +32,7 @@ class StreamedRequest extends BaseRequest {
/// buffered.
///
/// Closing this signals the end of the request.
EventSink<List<int>> get sink => _controller.sink;
StreamSink<List<int>> get sink => _controller.sink;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that you need to update the example in the documentation for this class.

@natebosch
Copy link
Member Author

natebosch commented Jun 16, 2023

cc @jakemac53 - this change isn't directly breaking, but with a typical linting setup that uses unawaited_futures the change pushes for edits that would cause breakage - with the IO client the sink.close() and request.send() calls return cross-dependent futures. The call to close() returns a Future that cannot complete until the request is sent, and the call to send() returns a Future that cannot complete until the sink has been closed.

pkgs/http/lib/src/streamed_request.dart Outdated Show resolved Hide resolved
Prefix all lines of the commment-in-example-in-comment with `//`.
Fix grammar. Remove "generally".
Remove redundant mention of the not completing future - it's more clear
to state it above the `unawaited` in the example code.
@natebosch natebosch merged commit ff1fcfe into master Jun 20, 2023
12 of 13 checks passed
@natebosch natebosch deleted the stream-sink branch June 20, 2023 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

StreamedRequest.sink should be a StreamSink
3 participants