Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

tracer.xml overridden error handling #4

Open
ckho opened this issue Feb 17, 2020 · 13 comments
Open

tracer.xml overridden error handling #4

ckho opened this issue Feb 17, 2020 · 13 comments

Comments

@ckho
Copy link

ckho commented Feb 17, 2020

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.

image

Expected behaviour:
image

Actual behaviour after importing "tracer.xml":
image

@michaelhyatt
Copy link
Owner

Thanks for reporting it. What version are you using?

@ckho
Copy link
Author

ckho commented Feb 18, 2020

Mule: 4.1.6
elastic-apm-mule4-agent: 0.0.3 (built from distributed-http-tracing branch)

@michaelhyatt
Copy link
Owner

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?

@ckho
Copy link
Author

ckho commented Feb 18, 2020

Justed tested again with master and 4.1.6. The error is still overridden.

@michaelhyatt
Copy link
Owner

michaelhyatt commented Feb 18, 2020 via email

@ckho
Copy link
Author

ckho commented Feb 18, 2020

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?

@ckho
Copy link
Author

ckho commented Feb 18, 2020

I just find out something. The issue exists only when the error is handled in a flow reference.

Mule: 4.1.6
elastic-apm-mule4-agent: 0.0.2 (master)

The one that works well:
image

The one that doesn't work:
image

@ckho
Copy link
Author

ckho commented Feb 18, 2020

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.

@michaelhyatt
Copy link
Owner

michaelhyatt commented Feb 18, 2020 via email

@ckho
Copy link
Author

ckho commented Feb 19, 2020 via email

@ckho
Copy link
Author

ckho commented Mar 11, 2020

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.

@michaelhyatt
Copy link
Owner

michaelhyatt commented Mar 11, 2020

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.

@michaelhyatt
Copy link
Owner

michaelhyatt commented Mar 11, 2020 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants