APM instrumentation for a class should preempt CSEC’s to avoid NoOpTransactions

[lovesh-ap]

Encountered challenges while trying to instrument the http4s-ember-server for intercepting incoming requests. CSEC's current approach involves instrumenting the same method that the APM agent targets. org.http4s.ember.server.EmberServerBuilder.withHttpApp(Kleisli<F, Request<F>, Response<F>> httpApp)

However, we’re experiencing an issue where the CSEC instrumentation appears to be superseding that of the APM’s. This occurs because the APM’s createScalaTxnTracer() method, responsible for starting transactions, is called after the CSEC code executes. Consequently, CSEC encounters a NoOpTransaction scenario. This behavior has been substantiated by the findings in the APM logs.
Starting a transaction within CSEC isn’t a viable option either; based on our previous discussions, this action might lead to failures in Automated Integration Tests (AITs).

Feature Description

The APM instrumentation for the same class/package should preempt CSEC’s to avoid these complications.
Alternatively, might there be a different mechanism we could employ to initiate the transaction, one which would guarantee its precedence in the execution order, as opposed to relying on the createScalaTxnTracer() method? which should not affect any of our current users or AITs.

[workato-integration]

https://new-relic.atlassian.net/browse/NR-259473

[obenkenobi]

@lovesh-ap I sent a PR to the csec agent's http4s branch that resolved the NoOp transaction issue. Setting the instrumentation priority to -1 resolved the issue.