List<protocol.PluginPrint> pluginPrints = [];There is potential for this to get very long. Especially if some prints have been accidentally left in production plugin code, and a user has a long-running IDE session.
Should we implement this with a Queue from the get-go, with a max size, dropping the oldest messages as new ones are received?
response.error,This is maybe interesting. When we wrap the AnalysisRule calls in an additional zone, synchronous errors become treated like async ones, and we no longer receive a RequestError. Instead, as in the test above, we get a PluginError notification. Shouldn't be a difference for the user; it's just a different underlying reporting mechanism is in play.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
List<protocol.PluginPrint> pluginPrints = [];There is potential for this to get very long. Especially if some prints have been accidentally left in production plugin code, and a user has a long-running IDE session.
Should we implement this with a Queue from the get-go, with a max size, dropping the oldest messages as new ones are received?
I think we should. As it is this is effectively a memory leak.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brian WilkersonThere is potential for this to get very long. Especially if some prints have been accidentally left in production plugin code, and a user has a long-running IDE session.
Should we implement this with a Queue from the get-go, with a max size, dropping the oldest messages as new ones are received?
I think we should. As it is this is effectively a memory leak.
Done, and I turned the list into a map, so that if there is one very verbose plugin, it won't overwhelm the list of print messages from other plugins.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
if (prints != null && prints.isNotEmpty) {Can this ever happen? (I think that if there's a value then the list always has at least one element.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
if (prints != null && prints.isNotEmpty) {Can this ever happen? (I think that if there's a value then the list always has at least one element.)
Hmm I guess not. I can tidy that up.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Brian, sorry I had to regenerate some more files; PTAL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sorry Brian, I had to regenerate files and PluginPrint.java was added this time; PTAL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
No problem.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
DAS plugins: Add print-debugging support in Insights pages.
Work towards https://github.com/dart-lang/sdk/issues/61868
This adds a new notification type, 'PluginPrint'. There are several
fields and variables then named 'pluginPrint' or 'print', and I am
definitely open to changing these names, but this is the best one that
I thought of.
PluginPrint has three fields: The name of the plugin that printed, the
message that was printed, and the timestamp.
We wrap each plugin's AnalysisRule invocations with a zone, so that
the `print` handler can know the name of the plugin. The prints are
caught and sent to the server isolate as Notifications. The
PluginIsolate then stores the collected prints. The Plugins Insights
page can then retrieve them and display them.
Manual testing, with 1000 libraries that get new lint reported once per
file, I did not observe a negative performance impact.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |