You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
<Project>
<TargetName="Outputsomestuff">
<ExecCommand="( 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:
line1
...
line100
myerror
lineend
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.
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).
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: