feat(cupertino): throw on close with active requests

[brianquinlan]

Makes #1894 more diagnosable by changing CupertinoClient.close to throw if there are pending requests. So long as the developer remembers to call close before the isolate exists, they will be warned (through the exception) that they did not wait for all of requests to complete.

Also makes it more clear that Client.close must be called.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.

[github-actions]

PR Health

License Headers ✔️

// Copyright (c) 2026, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/cupertino_http/example/example.dart
pkgs/http/example/main.dart
pkgs/http_multi_server/test/cert.dart

This check can be disabled by tagging the PR with skip-license-check.

Unused Dependencies ⚠️

Package	Status
cupertino_http	❗ Show Issues These packages are used outside lib/ but are not dev_dependencies: * flutter * integration_test These packages are only used outside lib/ and should be downgraded to dev_dependencies: * hooks * logging * native_toolchain_c These packages may be unused, or you may be using assets from these packages: * dart_flutter_team_lints Failed to update packages.
http	❗ Show Issues These packages may be unused, or you may be using assets from these packages: * dart_flutter_team_lints * shelf

For details on how to fix these, see dependency_validator.

This check can be disabled by tagging the PR with skip-unused-dependencies-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

Coverage ⚠️

File	Coverage
pkgs/cupertino_http/lib/src/cupertino_client.dart	💔 Not covered
pkgs/http/lib/src/client.dart	💚 100 %
pkgs/http/lib/src/io_client.dart	💚 89 %

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check.

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
cupertino_http	Breaking	2.4.0	3.0.0-wip	3.0.0-wip	✔️
http	None	1.6.0	1.6.1-wip	1.6.1-wip	✔️

This check can be disabled by tagging the PR with skip-breaking-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbol	Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

[natebosch]

Makes #1894 more diagnosable.

Could you elaborate on this a bit? How does it help with the diagnosis?

[natebosch]

I think it's OK to do this either way, but is there precedence for clients that throw if they are closed while requests are ongoing? I can't recall the behavior of our existing clients.

[natebosch]

[optional] since the pr already touches the single usage point, consider renaming to _responseHeaders

https://dart.dev/effective-dart/design#avoid-starting-a-method-name-with-get

[brianquinlan]

Makes #1894 more diagnosable.

Could you elaborate on this a bit? How does it help with the diagnosis?

I changed the wording a bit - is it better?

[brianquinlan]

I think it's OK to do this either way, but is there precedence for clients that throw if they are closed while requests are ongoing? I can't recall the behavior of our existing clients.

package:cronet_http has the behavior because the underlying cronet library has this behavior - if you call shutdown while there pending requests, you get an exception.

[natebosch]

is it better?

Yes thanks