devtools_extensions: asyncEval fails on web targets

[adsonpleal]

This issue is for devtools_extensions.

asyncEval is not working for debug services running for web targets. Other targets (tested on MacOS) work fine.

Whenever I call asyncEval on a web target I get the following error:

ChromeProxyService: Failed to evaluate expression 'postEvent': InternalError: frontend server failed to compile '() { return
postEvent; }'.

A simple eval like this already throws the error:

final eval = EvalOnDartLibrary(
  'dart:core',
  serviceManager.service!,
  serviceManager: serviceManager,
);

await eval.asyncEval('Future.value(42)', isAlive: isAlive)

@kenzieschmoll I encountered this error while working on the shared_preferences_tools issue.

[kenzieschmoll]

@elliette any idea what that ChromeProxyService error is related to? or why async evals would be broken on the web?

[elliette]

I did a little investigation into this, but unfortunately I know very little about how expression evaluation works. @nshahan and @Markzipan might have more context here.

• The evaluation that is causing an issue is this first eval to postEvent which I see from the comment was added as a "workaround".
• DWDS converts the postEvent expression to a lambda function () {return postEvent;}
• And then the call to the FrontendServerClient to compile the expression to JS is failing with the error seen above: InternalError frontend server failed to compile '() { return postEvent; }'

I think the easiest solution would probably be to avoid sending the postEvent workaround if possible, otherwise this will require modifying the frontend server client. FYI @CoderDake as well

[adsonpleal]

@kenzieschmoll, I think we'll need to solve this issue before merging flutter/packages#6749. If we merge the PR before this fix the extension won't work for web targets.

[kenzieschmoll]

I don't think we can avoid the postEvent call here, otherwise we would not complete the future that waits for the extension event here:

devtools/packages/devtools_app_shared/lib/src/service/eval_on_dart_library.dart

Line 397 in 0547de5

return event.extensionKind == 'future_completed' &&

@nshahan or @Markzipan - do you know what would it take to fix the issue that @elliette described?

[nshahan]

@kenzieschmoll
Can you help me understand the priority of this request?

I spent a little time investigating but didn't get to any definitive answers. I did notice two of our expression evaluation tests are currently skipped with comments that the features are not supported at this time. They are evaluating an expression in the context of an SDK library, and await in an expression evaluation. I believe those features could be blocking this request. From the history, I can't really tell if those are big projects to get working or not.

@sigmundch mentioned that he might have time to take a look at the feasibility of getting something working quickly.

[kenzieschmoll]

This is blocking the package:shared_preferences DevTools extension from landing (flutter/flutter#145433), and I think this is causing errors in the package:provider DevTools extension as well, which also uses asyncEval: #6103.

@sigmundch if there was a way to get something working quickly, that would be ideal. Otherwise, we may have to have these extension author disable the extension for Web users, or remove the asyncEval utility completely from our devtools_app_shared package (which would be breaking for all DevTools extensions already using this utility).

CC @bkonyi if you have any suggestions based on how these evaluations are supported for the VM.

[sigmundch]

I took brief look yesterday and don't have a good gauge on the complexity, yet. Looking back at the history behind this, the skip has been there for nearly 4 years, so I wouldn't be surprised if adding eval support within the SDK could be something that requires some non-trivial effort.

If that's the case, my inclination is to either look for workarounds or disable these extensions on Web. There are two workarounds I think are feasible here to remove the use of the evan-in-SDK from this workflow:

• expose postEvent in the bootstrap logic
• import postEvent in the snippet of JavaScript we generate for expression evaluation

[nshahan]

Looking back at the history behind this, the skip has been there for nearly 4 years, so I wouldn't be surprised if adding eval support within the SDK could be something that requires some non-trivial effort.

Another possibility is that the support was not needed at the time and just went to the backlog until someone requested it like they are now. It could be not much work but our problem right now is that no one is knowledgeable enough about this part of the stack to know if it is or not.

[elliette]

This would also be quite a bit of work (both for web and non-web), but I wonder if long-term it would make sense to add an asyncEvaluate method to the VM Service? From my understanding, DevTools has its own asyncEval implementation because the regular evaluate provided by the VM service doesn't support awaiting Futures. That way DevTools wouldn't need a custom implementation depending on postEvent.

[sigmundch]

Quick update: currently the expression-compiler (used indirectly via dwds) relies on many pieces to properly support expression evaluation that are not available for the Dart SDK today (e.g. properly plumbed full dill files, source-maps, potentially other metadata). As such, I believe that full expression evaluation support in the SDK would be large effort and not worth it at the moment.

However, since the use here for postEvent only requires a library-level eval, I believe we can elide some of the steps of expression evaluation. In particular, there is no need for a full dill to find the enclosing scope, since we know the scope is simply a library. It's not implemented that way today, but it may be possible to change his to support this use case. I'll investigate this further and share any updates.

[sigmundch]

I found a way to support library level evaluation locally in the expression compiler service. I just sent CL 367981 out for review.

The CL only covers the changes needed in the SDK. I don't believe we need changes in DWDS or flutter tools, but I haven't tested that either, so there is a chance we need to do some additional tweaks.

@kenzieschmoll or @elliette - do you have instructions or an easy way to validate it all works end to end with a custom build of the SDK? Thanks!