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

"InternalError: No batch result object ID" error when inspecting getters #59766

Closed
Reprevise opened this issue Dec 19, 2024 · 5 comments
Closed
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@Reprevise
Copy link

I'm using VSCode, Dart 3.6.0 (Flutter 3.27.1) and sometimes when debugging I get InternalError: No batch result object ID. errors instead of the computed getter values. This is happening when making a Flutter web app.

image

@dart-github-bot
Copy link
Collaborator

Summary: Debugging Flutter web app in VS Code (Dart 3.6.0) yields InternalError: No batch result object ID when inspecting getter values. Inconsistently reproducible.

@dart-github-bot dart-github-bot added area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Dec 19, 2024
@biggs0125
Copy link

Hi @Reprevise, would you mind including a code snippet where you've run into this to help us reproduce the issue?

@Reprevise
Copy link
Author

Reprevise commented Dec 19, 2024

Hi @biggs0125. I can reproduce the problem in this code sample:

import 'package:flutter/material.dart';

void main() {
  runApp(const MainApp());
}

class MainApp extends StatelessWidget {
  const MainApp({super.key});

  Iterable<int> _numbers() sync* {
    for (var i = 1; i <= 10; i++) {
      yield i;
    }
  }

  @override
  Widget build(BuildContext context) {
    final _ = _numbers();

    return MaterialApp(
      title: 'Sample App',
      home: const Column(
        children: [
          Text('Sample'),
        ],
      ),
    );
  }
}

Logs in VS Code's Debug Console:

ChromeProxyService: Failed to evaluate expression 'x.iterator': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.length': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.isEmpty': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.isNotEmpty': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.first': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.last': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.single': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.hashCode': InternalError: No batch result object ID..
ChromeProxyService: Failed to evaluate expression 'x.runtimeType': InternalError: No batch result object ID..

@biggs0125
Copy link

Thanks for the snippet, this helped me reproduce this locally! For posterity I added a breakpoint after _numbers was called. Then in the variables panel expanding the fields on the resulting _SyncStarIterable reproduced the errors above.

I made some local changes to dwds (the debug service talking to the Chrome debugger API) and was able to get more information on these errors:
For efficiency, it batches requests to the Chrome debugger API into a single expression evaluation (by wrapping all the subexpressions in a JS array). So the expression it asks Chrome to evaluate is really something like [x.iterator, x.length, x.isEmpty,...]. The problem occurs when any of these subexpressions throws. This causes the whole batch of expressions to fail.

In the case of the example you provided, the failing expression is x.single. The iterable has more than one element so that throws.

There's really no way to know if an expression is going to throw without trying to evaluate it first. But we can add a retry mechanism that unbatches them if the batched version fails.

I've opened a issue for this in the dwds package: dart-lang/webdev#2551

I also have a fix I'll work on landing there but it may take some time for that change to roll into Flutter tools.

Workaround:
In the meantime I recommend using the "Watch" panel to evaluate specific getters you care about on variables that fail. This will avoid the batching issue.

@biggs0125
Copy link

Marking as closed and tracking fix in dart-lang/webdev#2551

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

3 participants