Tolerate AbstractMethodError for servletRequest remote port

[amarziali]

What Does This Do

We have telemetry signals like this:

java.lang.AbstractMethodError
    at (redacted)
    at datadog.trace.instrumentation.servlet3.Servlet3Decorator.peerPort(Servlet3Decorator.java:67)
    at datadog.trace.instrumentation.servlet3.Servlet3Decorator.peerPort(Servlet3Decorator.java:14)
    at datadog.trace.bootstrap.instrumentation.decorator.HttpServerDecorator.onRequest(HttpServerDecorator.java:331)
    at datadog.trace.instrumentation.servlet3.Servlet3Decorator.onRequest(Servlet3Decorator.java:105)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
    at (redacted: 9 frames)

While this decorator works with a servlet 3 that would have bundled this method (getRemotePort is available from servlet 2.4 onward) it looks like some underlying request objects have not implemented it.

Muzzle should prevent linkage issues with the loaded runtime because (references):

datadog.trace.instrumentation.servlet3.Servlet3Instrumentation
  public interface javax.servlet.http.HttpServletRequest
   .....
       Method: public_or_protected non_static getAttribute(Ljava/lang/String;)Ljava/lang/Object;
    Method: public_or_protected non_static setAttribute(Ljava/lang/String;Ljava/lang/Object;)V
    Method: public_or_protected non_static getUserPrincipal()Ljava/security/Principal;
    Method: public_or_protected non_static getServletContext()Ljavax/servlet/ServletContext;
    Method: public_or_protected non_static getMethod()Ljava/lang/String;
    Method: public_or_protected non_static getRemoteAddr()Ljava/lang/String;
    Method: public_or_protected non_static getRemotePort()I

Now what can happen (but we cannot prove it) is that the underlying application is wrapping the request with a ServletRequestWrapper that's been compiled against an older servlet version. In this case, when the JVM do the invokeInterface it may hits the AbstractMethodError because not present in the bytecode.

This PR ensure that the error is properly ignored and that the full advice is not interrupted because of this.

Hence we do not surface the error in the telemetry since now it's handled (but we log in debug in case)

Motivation

Additional Notes

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

Jira ticket: [PROJ-IDENT]

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.

[mcculls]

Approving as speculative fix, which we'll check by seeing if telemetry changes

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-18 16:20:05 UTC ℹ️ Start processing command /merge

---

2026-05-18 16:20:10 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-05-18 17:35:35 UTC ℹ️ MergeQueue: This merge request was merged