Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fatal errors not reported in vercel logs #524

Open
fascinated opened this issue Mar 3, 2024 · 4 comments
Open

Fatal errors not reported in vercel logs #524

fascinated opened this issue Mar 3, 2024 · 4 comments

Comments

@fascinated
Copy link

I have a few basic "route all requests to php"-style deployments on vercel, and I am noticing that when these deployments encounter a Fatal Error (for ex, some silly type issue like trying to read from a null as if it was an array ;p), the Fatal error message does not appear in the Vercel logs.

Has anyone else encountered this? Is there a workaround?

My only php.ini tweak is "display_errors = Off", which shouldn't affect this.

Using this simple vercel.json, for reference:

{
    "functions": {
        "api/*.php":
        {
            "runtime": "[email protected]",
            "maxDuration": 60
        }
    },
    "rewrites": [
        {"source": "/(.*)", "destination": "api/routes.php"}
    ]
}
@f3l1x
Copy link
Collaborator

f3l1x commented Mar 3, 2024

Hi @fascinated, so far I didn't check Vercel logs for this type of exceptions, I must take a look.

@fascinated
Copy link
Author

Thanks for the quick response <3.

Here's an example "fatal error" script, this will return 500 as expected, but the error itself will not be in the logs:

    $bad_var = null;
    if(in_array("test", $bad_var['not_array'])) { 
        echo "we shouldn't be here ;)";
    } else {
        echo "TEST OK: value not found";
    }

Screenshot_2024-03-03_at_11_48_16

It's also worth noting that if you change this script to something like [below] such that there's some output before the fatal error, then Vercel will not report a 500 at all (and the logging behavior is the same). I sorta get why this is (200 header + output already sent), but if memory serves right, the common nginx/php-fpm setup would still produce an error in this case. Is this one a buffering issue specifically?

    $bad_var = null;
    echo "OK";
    if(in_array("test", $bad_var['not_array'])) { 
        echo "we shouldn't be here ;)";
    } else {
        echo "TEST OK: value not found";
    }

Screenshot_2024-03-03_at_11_51_39

@f3l1x
Copy link
Collaborator

f3l1x commented Mar 3, 2024

Under the hood, there is simple PHP built-in development server.

If you start your script like that php -S 0.0.0.0:8080 api/index.php you can see what is on stdout and what on stderr. Maybe it's wrong in built-in server.

@fascinated
Copy link
Author

Yeah, I was thinking it's some stdout/stderr thing, but it seems all of the output from php -S just goes to stderr, so maybe there's something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants