Repository navigation
When using the "Restart Analysis Server" command, record a log with some diagnostic info #5513
Description
See dart-lang/sdk#60540 (comment)
Some users use this command periodically but not enough to get a prompt encouraging filing a bug. It's also difficult to collect info after the fact (and it may not be appropriate to try to debug while you're in the middle of something and the analyzer breaks).
We should have this command automatically record some logs - for example the last traffic from the analyzer and the usual log header info. Each file should be new (with a timestamp in the name) to avoid any overwriting. This way if someone is using this command they may be able to provide or review these log files for possible patterns.
(ideally we'd get the instrumentation log, because it contains watch events and server-side errors.. but I don't think there's a good way to do this).
Activity
FMorschel commentedon May 26, 2025
I'm not sure, but I think @bwilkerson was thinking a while back about a smart way to detect infinite loops. If we can, cases like dart-lang/sdk#60785 could be caught. I suspect some users might not notice that they have problems like this, so they would not open issues or ask around, but simply solve their problem.
As a note, Brian, I was the one who found the above-mentioned issue, but I asked Dan first if he could also reproduce it. In my case, I completely finished my refactor (from if-case to switch statement), and then I noticed my analyzer was never updating the diagnostics.
DanTup commentedon May 27, 2025
It would definitely be nice to detect loops like that in the parser, though I don't know what portion of users using this command are doing so because of parser loops (nor do I know if we'd easily track those down from a client-side log as I had in mind here). My main goal here is to get some more reports from users that are using this command.
I resisted adding this command for a long time because I was worried that people would just use it quietly to solve their immediate issue but the underlying bugs might go unreported. Unfortunately that seems to have been the case. I can see a lot of people use this command, but I haven't seen many issues created because of it. If you use it a few times in a single session, it'll prompt you to file an issue - but I suspect most people use it infrequently enough that this doesn't trigger. It would be nice to reduce that threshold, but we should ensure we're providing some more useful information at the same time.
bwilkerson commentedon May 27, 2025
I have put a fair amount of thought into ways of detecting infinite loops in the
dart fixcommand so that we can remove the current limit on the possible number of iterations, but I wasn't proposing any general solution to find infinite loops in other code. The general case isn't possible in general.Unfortunately true. Developers (and I include myself here) tend to be very pragmatic; it usually takes less time to deal with one occurrence of a bug than to report it in a useful way. I'm currently spending some cycles thinking about ways to make it easier for users to report issues in an attempt to overcome that tendency. If you have ideas I'd love to hear them (though maybe not on this issue so as to not hijack it).
DanTup commentedon Jun 9, 2025
For the original issue here, I've added a notification when you use the "Restart Analysis Server" command that now shows that the server was restarted and has a "Show Log" button. It opens a log file that contains the standard log header and the contents of the log buffer (the last 500 events to be logged by the extension prior to restarting). It will show this each time you use the command (which is up from only if you use it 10 times in a single session), but since my assumption is that this command is used fairly infrequently, I think that's probably ok. If anyone is using it a lot in a single session, then I do think they should be filing issues.
I would like to encourage people to file issues, but at this point I don't know how often this command is used or how useful this log (which is on the client so doesn't include things like server watch events), so it might be better to have fewer reports initially while we refine this (cc @jakemac53 🙂).
jakemac53 commentedon Jun 9, 2025
Yeah having that seems quite useful and should lower one of the barriers to filing bugs.
Show a button to dump the current log buffer when "Restart Analysis S…