pjfanning opened a new pull request, #3473: URL: https://github.com/apache/pekko/pull/3473
### Motivation The OpenTelemetry Java agent propagates trace context through pekko actors, streams and remoting by attaching bytecode advice to specific internal methods. Its muzzle checks verify the classes and methods the *advice code calls*, not the method *matchers*, so a matched method that is renamed, inlined or restructured just stops matching — no error, no log, silently broken propagation. This is the pekko-core counterpart of apache/pekko-http#1240, which does the same for pekko-http. ### Modification - Documented each matched method where it is declared: which agent depends on it, what the agent uses it for, and a link to the instrumentation source. - Marked those methods `@noinline` so the compiler cannot inline them out of the bytecode, following the existing precedent in `Envelope.copy`, `MessageBuffer` and `Dispatch.stop`. - Listed the `RemoteInstrument.identifier` values known to be taken (0 Lightbend Telemetry, 1 Pekko's own `LoggingRemoteInstrument`, 8 Kamon, 9 OpenTelemetry) so the next implementer does not have to grep other projects for a free one. No API changes, no `@InternalStableApi` added. Documented symbols: | Module | Symbols | | --- | --- | | pekko-actor | `Dispatcher.dispatch`, `ActorCell.invoke`, `ActorCell.systemInvoke`, `DefaultSystemMessageQueue.systemEnqueue`, `LightArrayRevolverScheduler.schedule`/`scheduleOnce` | | pekko-stream | `GraphInterpreter.processPush` | | pekko-remote, artery | `RemoteInstruments.create`/`serialize`/`deserialize`, `ReusableOutboundEnvelope.init`/`copy`/`clear`, `ReusableInboundEnvelope.init`/`clear`, `artery.MessageDispatcher.dispatch` | | pekko-remote, classic | `EndpointManager.Send`, `EndpointWriter.writeSend`, `DefaultMessageDispatcher.dispatch`, `PekkoPduProtobufCodec.constructMessage`/`decodeMessage` | Links pin the pekko-actor and pekko-http instrumentation at OpenTelemetry commit `6f9ca5672ce84edbbe36ce0e14386c31d68f479f` (the same commit referenced from apache/pekko-http#1240). The remoting instrumentation is not merged upstream yet, so those comments link to open-telemetry/opentelemetry-java-instrumentation#19823 instead. ### Result The load-bearing internal APIs are recorded next to the code, so a refactor of one of them is visible to the person making it and can be called out in release notes. Three new `InstrumentationPointsSpec` suites assert by reflection that each matched name, arity and parameter type is still present in the bytecode, so a change that would silently disable the agent fails the build instead. ### Tests - `sbt "actor-tests/testOnly org.apache.pekko.dispatch.InstrumentationPointsSpec"` - 6 passed - `sbt "stream-tests/testOnly org.apache.pekko.stream.impl.fusing.InstrumentationPointsSpec"` - 1 passed - `sbt "remote/testOnly org.apache.pekko.remote.InstrumentationPointsSpec"` - 10 passed - `sbt actor/mimaReportBinaryIssues stream/mimaReportBinaryIssues remote/mimaReportBinaryIssues` - clean - `sbt scalafmtCheckAll scalafmtSbtCheck` - pass - `sbt headerCreateAll` - headers added for the three new files ### References Fixes #3472 Refs apache/pekko-http#1240 Refs open-telemetry/opentelemetry-java-instrumentation#19823 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
