[Bug]: aborting a http request with abort(404) produces "non-http" errors in APM

[rburgst]

Bug report

Write a controller and produce a 404 like so

class TestController extends Controller
{
    /**
     * Display a listing of the resource.
     */
    public function index()
    {
        abort(404, "not found")
    }

Then in the datadog apm those responses are classified as "non-http" errors:

PHP version

8.3.14

Tracer or profiler version

1.5.1

Installed extensions

bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
intl
json
ldap
libxml
mbstring
mysqli
mysqlnd
odbc
openssl
pcntl
pcre
PDO
pdo_dblib
pdo_mysql
PDO_ODBC
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
pspell
random
readline
redis
Reflection
session
shmop
SimpleXML
soap
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
xdebug
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Xdebug
Zend OPcache

Output of phpinfo()

{ "date": "2024-12-21T06:43:11Z", "os_name": "Linux 3b353a35b6a0 6.5.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 9 22:39:36 UTC 2024 aarch64", "os_version": "6.5.0-15-generic", "version": "1.5.1", "lang": "php", "lang_version": "8.3.13", "env": null, "enabled": true, "service": null, "enabled_cli": true, "agent_url": "http://localhost:8126", "debug": false, "analytics_enabled": false, "sample_rate": -1, "sampling_rules": [], "tags": [], "service_mapping": [], "distributed_tracing_enabled": true, "dd_version": "0.0.0", "architecture": "aarch64", "instrumentation_telemetry_enabled": true, "sapi": "fpm-fcgi", "datadog.trace.sources_path": "/opt/datadog/dd-library/1.5.1/dd-trace-sources/src", "open_basedir_configured": false, "uri_fragment_regex": null, "uri_mapping_incoming": null, "uri_mapping_outgoing": null, "auto_flush_enabled": false, "generate_root_span": true, "http_client_split_by_domain": false, "measure_compile_time": true, "report_hostname_on_root_span": false, "traced_internal_functions": null, "enabled_from_env": true, "opcache.file_cache": null, "sidecar_trace_sender": true, "agent_error": "Failed to connect to localhost port 8126 after 0 ms: Couldn't connect to server" }

Upgrading from

No response

[PROFeNoM]

Hey @rburgst 👋

As far as I've been able to reproduce, the top graph only shows this kind of "Non-HTTP" bar when under the "All Spans" view. The latter view includes the laravel.action span, marked as an error since abort() throws a NotFoundHttpException. This error doesn't have a status code, so it falls under the "Non-HTTP" Errors.
I don't see such bars while querying on "Trace Root Spans" or "Service Entry Spans".

Does the above represent the behavior you are experiencing? What behavior would you advocate for?

Thanks! 😃

[rburgst]

@PROFeNoM I am not sure I follow. The NotFoundHttpException produces a 404 http error. So I am a bit confused that those would show up as Non-HTTP Errors. Therefore I would expect the error to show up as a 404.

[ralphschindler]

Also seeing this behavior. Is it a laravel problem or a datadog classification problem? 🤔

[PROFeNoM]

Hi!

From my understanding of the issue, I'd describe the behavior as expected. This behavior is not Laravel nor dd-trace-php specific; This is how errors not associated with a status code are represented on this view.

On the above view, no errors are shown since the error is handled and doesn't bubble up to the root span.

On this view, others errors are shown since the error is happening on the laravel.action span and the latter isn't associated with an HTTP status code. It is, therefore, categorized as a Non-HTTP error, which is expected.

[ralphschindler]

I believe this is related to #3047

Laravel uses specific exceptions to control flow in an application. Namely, it will throw a Symfony\Component\HttpKernel\Exception\NotFoundHttpException which is expected to be caught by the ErrorHandler and subsequently turned into a valid/"normal" 404 response.

This exception can be throw early from the dispatcher when not able to find a matching route, or later inside a dispatch.action, inside a "controller" via the abort() method (the `abort() method is a shortcut for throwing the aforementioned exception type.)

The exception handler should be seeing this type as "not reportable". As it stands, it works correctly when the exception is thrown for unmatched routes, but does not work in cases where a controller is throwing the same exception type.

Edit: more to the point, the exception is being classified as an Error in datadog, instead of a normal request that ended in 404. To me it matters less that it would be classified as non-Http, though I do not see that in my environment.