tracer.xml overridden error handling
ckho opened this issue · 13 comments
In our current Mule application, we did a validation of value. If that does not pass, we will catch the error and then return a pair of error code and payload we set.
However, after importing the "tracer.xml", the error is overridden and becomes a 500 error.
Thanks for reporting it. What version are you using?
Mule: 4.1.6
elastic-apm-mule4-agent: 0.0.3 (built from distributed-http-tracing branch)
I built and tested it with 4.2.2, that branch is a bit of a dead-end where I experimented with few undocumented Mule APIs. Can you please test it with master?
Justed tested again with master and 4.1.6. The error is still overridden.
Can you try it on 4.2.2 please?
Sorry I can't test it on 4.2.2, because my environment is limited by the PCE version. I can only use Mule runtime up to 4.1.x.
Is there any way to enable more log for debugging?
One more finding:
All error handling in all flows except the ones listening to the HTTP requests are omitted.
I do an experiment with 3 flow:
Root flow: Listen to the http request. Call middle flow. Catch exception, create a variable "rootFlag" and return the value of all the flags.
Middle flow: Call lower flow. Catch exception and create a variable "middleFlag".
Lower flow: Do validation. Catch exception and create a variable "lowerFlag".
Only the error handling in root flow is executed.
I have drilled the code and done some experiment.
I found that if we add any hook, like exceptionally
or thenApply
, on action.proceed()
, the issue would occur.
This is tested on a raw project without adding the apm-agent.
I created a Mule project and then overrided both the ProcessorInterceptorFactory and ProcessorInterceptor.
Yes, agree, exception handling needs to be refined a bit further. I need to put together a quick design brief on how the exceptions should be handled within the APM agent: resuming the execution flow, capturing exception, etc.