Fix cancelled HTTP requests showing as Pending in DevTools Network tab by rishika0212 · Pull Request #9685 · flutter/devtools

rishika0212 · 2026-03-05T16:38:05Z

Description

This PR fixes an issue where cancelled HTTP requests appear as "Pending" in the DevTools Network tab.

When a request is aborted (for example using HttpClientRequest.abort or Dio cancellation), DevTools keeps the request in a Pending state because no response is received. This change detects such cases and displays the request status as "Cancelled" instead.

Changes

Detect cancelled/aborted requests in HttpRequestData
Display "Cancelled" instead of "Pending" in the Network table
Ensure cancelled requests are no longer treated as inProgress
Prevent duration from remaining null for cancelled requests
Add a regression test to verify the behavior
Update CustomPointerScrollView to use cacheExtent so the project compiles with the current Flutter SDK

All existing network tests pass locally.

Fixes: #9593

Pre-launch Checklist

I read the Contributor Guide and followed the process outlined there for submitting PRs.
I read the Tree Hygiene wiki page, which explains my responsibilities.
I read the Flutter Style Guide recently and followed its advice.
I signed the CLA.
I listed at least one issue that this PR fixes in the description above.
I added tests to check the change I am making.

If you need help, consider asking for help on Discord.

srawlins

This code looks great; thanks for the PR! I'd like to test manually before landing.

srawlins · 2026-03-06T03:26:54Z

packages/devtools_app/lib/src/shared/primitives/custom_pointer_scroll_view.dart

    super.shrinkWrap,
    super.padding,
-    super.scrollCacheExtent,
+    super.cacheExtent,


CC @elliette ; from the PR description:

Update CustomPointerScrollView to use cacheExtent so the project compiles with the current Flutter SDK

bkonyi

LGTM overall!

packages/devtools_app/lib/src/shared/http/http_request_data.dart

packages/devtools_app/lib/src/screens/network/network_request_inspector_views.dart

srawlins · 2026-03-16T17:44:13Z

Hi @rishika0212 sorry for the delay. I've been manually testing this and I have a clarifying question:

I use the devtools_companion app to test the Network panel. I've got a PR that adds "cancellation" support: elliette/devtools_companion#23.

I've observed behavior that seems questionable to me, but you might shed some light. Take this series of steps:

Send a GET request.
The server starts to send a response, (the "Response Body" checkbox is checked).
After 1 second, the request is cancelled by the client.
The server never closes the response.

After these steps, I do not see the Cancelled status (it seems to remain Open). However, if the server never starts to send a response (the "Response Body checkbox is not checked), then the Cancelled status appears as expected.

I think the Cancelled status should still appear, even if the server has started to respond. But I am not an HTTP expert. WDYT?

srawlins · 2026-03-16T17:45:26Z

Oh, additionally, the other problem I observed is that the table will always show the Cancelled status before a server completes its response, even if the request was not in fact cancelled. I'll double check when this behavior occurs, but I observed it in the DevTools Companion app.

rishika0212 · 2026-03-17T12:47:07Z

Hey @srawlins

thanks again for the detailed repro, this was super helpful. I ran through it carefully using devtools_companion (including your srawlins/cancel case) and your exact sequence.

Here’s what I’m seeing:

Completes → behaves as expected (200)
Does not complete → stays pending (-), as expected
Cancelled before completion → now correctly shows as cancelled

I also tightened up the DevTools logic a bit to avoid showing “Cancelled” too early before a response actually completes.

For the specific edge case you mentioned (response starts, then gets cancelled after ~1s):
I agree that ideally this should show as Cancelled.

However, from what I can tell, this case doesn’t always come through with a clear cancellation signal in the HTTP profile data. Sometimes it still ends up looking like a normal 200 style response, which makes it tricky for DevTools to classify it confidently based on the current fields.

So overall from what I can tell…

The original issue (Cancelled showing as Pending) should now be fixed
The “response-started then cancelled” case seems more like a limitation in the profiling signal (companion/VM service), rather than just UI logic

Let me know if you’re seeing anything different on your side!

srawlins · 2026-03-17T16:53:48Z

I also tightened up the DevTools logic a bit to avoid showing “Cancelled” too early before a response actually completes.

Do you mean you've done this before today, or you will upload a commit?

rishika0212 · 2026-03-17T17:04:36Z

I also tightened up the DevTools logic a bit to avoid showing “Cancelled” too early before a response actually completes.

Do you mean you've done this before today, or you will upload a commit?

Before your comment, I hadn’t specifically tested the “cancel before complete” path in this depth, but after your note I ran those scenarios in devtools_companion, improved the classification logic, and added tests.

I can push the tested improvements now (mainly the cancelled vs pending behavior). The “response already started, then cancelled” case is still not fully reliable yet since the profiling signal is ambiguous in some runs.

rishika0212 · 2026-03-17T17:11:05Z

Right now, in the “response started, then client cancels” case, the profile payload can sometimes look like a normal 200 response. When that happens, the UI doesn’t really have a reliable way to tell the difference between:

a real completion
a request that got cancelled midway

So unless we get a clear signal from upstream (like wasCancelled, a dedicated cancel event, or a specific error field), we’re basically guessing. And that guess can go wrong in both directions:

if we’re too aggressive → we show false Cancelled
if we’re too conservative → we miss actual cancellations

srawlins · 2026-03-17T22:24:25Z

I can push the tested improvements now (mainly the cancelled vs pending behavior).

That would be great!

The “response already started, then cancelled” case is still not fully reliable yet since the profiling signal is ambiguous in some runs.

This sounds OK to me.

rishika0212 · 2026-03-18T17:02:46Z

I can push the tested improvements now (mainly the cancelled vs pending behavior).

That would be great!

I've pushed the updates.

srawlins

Just a couple of small changes; thanks!

srawlins · 2026-03-23T04:38:51Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    'cancel',
+    'canceled',
+    'cancelled',
+    'operation canceled',


Since we are just searching in a String for these values, we either don't need the longer ones ("operation canceled") or we don't need the shorter ones ("canceled").

I think it is find to just keep the shorter ones.

Are these values derived from some general libraries, like the dio package and dart:io?

Yes, they’re derived from cancellation wording observed in common Dart HTTP stacks, specifically our dart:io, package:http, and dio companion flows and the resulting VM profile payload strings.

srawlins · 2026-03-23T04:39:45Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    'cancelled',
+    'operation canceled',
+    'operation cancelled',
+    'abort',


I think we should remove the shortest two in this list, "cancel" and "abort." Unless there are examples from dart:io, package:http, or package:dio, where a cancelled error/event contains "cancel" or "abort" but not "cancelled"/"canceled" or "aborted."

Thanks for the suggestions, I’ve updated things accordingly.

I kept just canceled, cancelled, and aborted, and removed the longer phrases like operation canceled / operation cancelled since we’re already doing substring matching. I also dropped the more generic terms like cancel and abort to avoid false positives.

These markers are based on the cancellation wording we’ve seen in related flows (like dart:io request.abort(), package:http client.close(), and dio cancelToken.cancel(...)) along with the profiler payload text.

One thing to note: in companion cancel mode, we can still get a 200 since the status gets set early so in those cases, classification relies on explicit cancellation text in the error/event payloads.

packages/devtools_app/lib/src/shared/http/http_request_data.dart

packages/devtools_app/release_notes/NEXT_RELEASE_NOTES.md

packages/devtools_app/test/screens/network/network_controller_test.dart

…test teardown

elliette · 2026-03-30T22:21:14Z

packages/devtools_app/lib/src/screens/network/network_request_inspector_views.dart

  Widget _buildHttpTimeGraph() {
    final data = this.data as DartIOHttpRequestData;
-    if (data.duration == null || data.instantEvents.isEmpty) {
+    if (data.duration == null ||


[nit] pull data.duration into a named variable (e.g. requestDuration) so that we don't need the ! null assertion operator (data.duration!)

elliette · 2026-03-30T22:31:50Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    if (value == null) return false;
+    final normalized = value.toLowerCase();
+
+    /// Markers used for substring matching against request / response errors


[nit] since this is no longer a static const field, use normal comment markers \\ instead of the dartdoc \\\

elliette · 2026-03-30T22:32:54Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    }
+
+    if (isCancelled) {
+      return Duration.zero;


I think it could still be beneficial to include timing information even if the request was canceled - this matches what Chrome DevTools network panel does.

elliette · 2026-03-30T22:35:17Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

-    if (inProgress || !isValid) return null;
-    // Timestamps are in microseconds
-    return _endTime!.difference(_request.startTime);
+    if (_hasError) {


What are these changes for? It looks like the _endTime getter already takes into account whether or not there is an error so I don't think we need to change any of this logic.

elliette · 2026-03-30T22:37:58Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+      return false;
+    }
+
+    final statusCode = _request.response?.statusCode;


I understand why adding the isCancelled check is necessary, but why did the rest of the logic here change?

elliette · 2026-03-30T22:39:55Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    final statusCode = _request.response?.statusCode;
+    if (statusCode != null) return statusCode.toString();
+
+    if (_hasError) return 'Error';


I think we want to keep the _hasError check before the status code check to preserve the previous order, e.g.

if (isCancelled) return 'Cancelled`; if (_hasError) return 'Error'; return _request.response?.statusCode.toString();

elliette · 2026-03-30T22:42:14Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

  @override
  String get uri => _request.uri.toString();

+  bool get isCancelled {


It looks like the only reason this is public is to expose it for tests. Can we instead make this private and in the tests check the status to determine whether or not a request is canceled?

Yep, agreed. I made it private and updated tests to assert via status instead of exposing isCancelled just for testing

elliette · 2026-03-30T22:46:41Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    if (_request.request?.error != null && _request.response == null) {
+      return true;
+    }
+
+    if (_request.endTime != null && _request.response == null) {
+      return true;
+    }


What are these checks for? It looks like these are checks for whether the request is in progress but I might be misunderstanding something here

Those checks were trying to catch cancelled requests when we don’t get a normal response, but I agree they also blurred into in-progress/completed logic. I removed them and kept cancellation detection focused on explicit cancellation signals, with completion handled separately

elliette · 2026-03-30T22:47:53Z

packages/devtools_app/test/test_infra/test_data/http_get_cancelled_json.dart

+    'persistentConnection': true,
+    'uri': 'https://jsonplaceholder.typicode.com/albums/1',
+  },
+  'response': null, // ← key: no response


Remove key comment

…l-safety; update related network tests

elliette

A few more suggestions but this is looking good, thank you!

elliette · 2026-03-31T16:53:50Z

packages/devtools_app/lib/src/screens/network/network_request_inspector_views.dart

-    if (data.duration == null ||
-        data.duration!.inMicroseconds == 0 ||
+    final requestDuration = data.duration;


My apologies for the back and forth here - looking at how this is used in _buildTimingRow, I have a better understanding of what this represents now.

It looks like this is the total duration of the request. I think we could make it a private getter _totalDuration that is used here and in _buildTimingRow.

Optionally also change the parameter names for _buildTimingRow:

label -> segmentLabel

duration -> segmentDuration

That should make the code more understandable.

elliette · 2026-03-31T16:59:25Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

-    if (inProgress || !isValid) return null;
-    // Timestamps are in microseconds
-    return _endTime!.difference(_request.startTime);
+    if (inProgress || !isValid) {


This method is now the same as it was before, revert to original code. Thanks!

elliette · 2026-03-31T16:59:58Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart


-  /// True if the HTTP request hasn't completed yet, determined by the lack of
-  /// an end time in the response data.
  @override


Please add dartdoc back

elliette · 2026-03-31T17:01:02Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

-      _hasError ? !_request.isRequestComplete : !_request.isResponseComplete;
+  bool get inProgress {
+    if (_isCancelled) return false;
+    return _request.endTime == null;


Should we still be checking for an error here along with using isRequestComplete/isResponseComplete?

I think inProgress should still consider error/request/response completion
Agreed. Updated inProgress to use request/response completion semantics (including the error path), with cancellation handled separately.

elliette · 2026-03-31T17:02:30Z

packages/devtools_app/lib/src/shared/http/http_request_data.dart

+    final statusCode = _request.response?.statusCode;
+    if (statusCode != null) return statusCode.toString();
+
+    return null;


This is equivalent to return _request.response?.statusCode.toString() (the original code) because the entire expression will evaluate to null if response is null

elliette · 2026-03-31T17:03:30Z

packages/devtools_app/test/screens/network/network_profiler_test.dart

        expect(find.text('GET'), findsOneWidget);
        expect(find.text('Status: '), findsOneWidget);
-        expect(find.text('Error'), findsOneWidget);
+        expect(find.text('Cancelled'), findsOneWidget);


Is the change from Error to Cancelled intentional/expected?

Yes, intentional. httpGetWithError uses a HandshakeException error string which doesn't contain any cancellation markers (cancelled, canceled, aborted), so it correctly resolves to 'Error'. The profiler test already expects 'Error' for that fixture.

elliette · 2026-03-31T17:03:40Z

packages/devtools_app/test/test_infra/test_data/http_get_cancelled_json.dart

@@ -0,0 +1,34 @@
+// Copyright 2020 The Flutter Authors


Fix cancelled HTTP requests showing as Pending in DevTools Network tab

45b1c2a

rishika0212 requested review from a team, bkonyi and kenzieschmoll as code owners March 5, 2026 16:38

srawlins approved these changes Mar 6, 2026

View reviewed changes

bkonyi approved these changes Mar 6, 2026

View reviewed changes

packages/devtools_app/lib/src/shared/http/http_request_data.dart Show resolved Hide resolved

rishika0212 and others added 4 commits March 10, 2026 17:55

Simplify inProgress getter logic

3ecd00f

Merge branch 'flutter:master' into fix-network-cancelled-status

d74f363

added release notes and fixed analyzer warnings

f5204f6

added release notes

39babfa

kenzieschmoll reviewed Mar 12, 2026

View reviewed changes

packages/devtools_app/lib/src/screens/network/network_request_inspector_views.dart Show resolved Hide resolved

Restored @VisibleForTesting annotations

2ad05f8

rishika0212 and others added 3 commits March 18, 2026 17:08

Improve network request status classification

54eafea

psuhing json

0503e54

Merge branch 'master' into fix-network-cancelled-status

d9162b6

rishika0212 requested a review from srawlins March 21, 2026 18:03

srawlins reviewed Mar 23, 2026

View reviewed changes

rishika0212 added 2 commits March 23, 2026 16:48

Improved cancellation status detection in Network profiler

0f7a854

Fix network cancellation test lints and typing

76cd92d

srawlins approved these changes Mar 24, 2026

View reviewed changes

Align network status test with cancellation behavior; stabilize eval …

8a50293

…test teardown

elliette requested changes Mar 30, 2026

View reviewed changes

Refine HTTP cancellation/status handling and network timing graph nul…

5de8e82

…l-safety; update related network tests

rishika0212 requested a review from elliette March 31, 2026 16:22

elliette requested changes Mar 31, 2026

View reviewed changes

Refine network cancellation logic and related tests.

d3d1ae7

rishika0212 requested review from elliette and srawlins March 31, 2026 17:58

Conversation

rishika0212 commented Mar 5, 2026

Description

Changes

Pre-launch Checklist

Uh oh!

srawlins left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkonyi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

srawlins commented Mar 16, 2026

Uh oh!

srawlins commented Mar 16, 2026

Uh oh!

rishika0212 commented Mar 17, 2026

Uh oh!

srawlins commented Mar 17, 2026

Uh oh!

rishika0212 commented Mar 17, 2026

Uh oh!

rishika0212 commented Mar 17, 2026

Uh oh!

srawlins commented Mar 17, 2026

Uh oh!

rishika0212 commented Mar 18, 2026

Uh oh!

srawlins left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elliette left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment