-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
CustomErrorRegularExpression errors are displayed poorly #840
Comments
Is there a simple .proj file that I could build myself to investigate this? |
Something like this I guess: <Project>
<Target Name="Outputsomestuff">
<Exec Command="( for /l %%x in (1, 1, 100) do ( echo line%%x ) ) & echo myerror & echo lineend" CustomErrorRegularExpression="myerror" />
</Target>
</Project> So in the output it's:
you can't tell where myerror actually is from binlog. |
@YuliiaKovalova @JanKrivanek this seems like a good bug if someone wants to try diving deeper into the viewer. The problem is that we extract all messages into a separate folder, and we extract errors into a different folder. We probably need to also extract the errors interspersed with the messages so that they get the timestamp too. This is happening here:
One problem that needs solving is it's super useful to have the errors in a separate folder. We could have them in two places, but that would result in duplication (and two results when searching for them). Something to think about. |
Errors are being bucketed into another folder here:
|
When CustomErrorRegularExpression of Exec task triggers over a bunch of log emitted to stdout, binlog viewer "plucks" the error messages out of the stdout into a separate item:
This makes it impossible to find where exactly the error happened in the stdout.
Meanwhile, normal log has the error messages displayed in correct order, allowing me to find where during execution the error actually happened, so I can see that it was between the NumberSequenceModuleSetup invocations:
Binlog viewer should handle this situation better. Probably by keeping the detected warning/error format strings in the full Messages dropdown.
The text was updated successfully, but these errors were encountered: