API Proxy with a shared flow disfunction when tracing enabled

[amitmarx]

Hey,
I have a shared flow responsible for sending request & response information to a logging server.
The shared flow contains a JS policy to construct the payload, and a ServiceCallout policy to actually send it in an async manner.
I've applied the shared flow using the Flow Hooks (using the Post-proxy hook).

It all works great until I start a trace session on the API Proxy.
When I use the trace, the original request to the API Proxy is hanged and basically the API Proxy is out of service.
Even when I stop the trace session, it still takes the API Proxy about 20 minutes to start work again.

Attached a PS from the trace window, notice that the transaction never completes.
In addition, even the fact the ServiceCallout policy missing in the tracing diagram, I see this request on my logging server.

Has anyone tackled this issue before, is this a bug in Apigee?
(I doubt it is an issue with the shared flow, as it works fine without the trace, but I'd be happy to be found wrong)
 

[dchiesa1]

I've not seen anything like what you are describing.

There is a problem the team is researching regarding the DebugSession (Trace) not working correctly in a chained proxy. But that has nothing to do with sharedflows, or flowhooks. Or a runtime error. It's just a trace error - missing data in the trace session.

I suggest you contact Apigee support to get help diagnosing this.

It all works great until I start a trace session on the API Proxy.

So you're saying that the API proxy and the sharedflow and the logging.... all of that works correctly, you get the logs in the log endpoint?

If I were diagnosing this, I might modify the sharedflow to selectively remove a few things. Like the ServiceCallout policy. If you remove that, does the "hang" still happen when Trace is enabled? What if you keep the SC policy and log a much smaller, even static message?

[amitmarx]

Yes - without the trace the Proxy works as expected and we see the log in the log endpoint.
When we enable the trace, we receive the log in the log endpoint, but the original request to the Proxy is hanged.

BUT,  we think we found a workaround:
Instead of using HTTPTargetConnection we added our logging endpoint as a Proxy and then called it from our shared flow via LocalTargetConnection.
From our tests it seems the trace doesn't affect it.