[Bug]: Warning: Undefined global variable $__herd_closure

[andyunleashed]

Platform

macOS

Operating system version

macOS 15.0 (24A335)

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.11.0 (Build: 33)

PHP Version

PHP 8.3.11

Bug description

When disabling all of the dump options or disabling interceptions via the toolbar button the app crashes out with the below:

Warning: Undefined global variable $__herd_closure in MyAppPath/bootstrap/app.php on line 22

Fatal error: Uncaught Error: Value of type null is not callable in MyAppPath/bootstrap/app.php:22 Stack trace: #0 /public/index.php(16): require_once()

1 /Applications/Herd.app/Contents/Resources/valet/server.php(167): require('MyAppPath...')

2 {main} thrown in ~/bootstrap/app.php on line 22

With the interceptions enabled, there are no errors or exceptions being logged at all.

This issue does not occur on PHP 8.2

Steps to reproduce

Basic herd install, no changes to the PHP configuration, just selecting PHP 8.3 as the version.

Then disabled interceptions or uncheck all options for logging.

Relevant log output

> Warning: Undefined global variable $__herd_closure in MyAppPath/bootstrap/app.php on line 22
> 
> Fatal error: Uncaught Error: Value of type null is not callable in MyAppPath/bootstrap/app.php:22 Stack trace: #0 /public/index.php(16): require_once() 
#1 /Applications/Herd.app/Contents/Resources/valet/server.php(167): require('MyAppPath...') 
#2 {main} thrown in ~/bootstrap/app.php on line 22

With the interceptions enabled, there are no errors or exceptions being logged at all.

[mpociot]

Could you check if the FPM 8.3 instance was successfully restarted? When toggling the dump interception or unchecking the logging options, we need to restart FPM in order to apply the changes.

I would assume that this (for some reason) didn't work for you.

Could you retry this after (Force) stopping all Herd services? You can do that by holding down the option key when you click on the menubar icon.

[andyunleashed]

The force stop and restart has indeed cleared the issue - I did originally do the regular start/stop but that didn't fix it so it seems maybe the standard stop didn't go through?

[mpociot]

Hm yeah maybe. Can you trigger the error again when toggling the dump interception?

I'll make sure that the FPM services always get (forcefully) stopped in this scenario so that you can't run into this issue 👍

[andyunleashed]

Toggling interception now doesn't seem to trigger the issue - the only thing I can think that may have caused it, is that I left all log options enabled when running hundreds of tests through the system previously, maybe it caused it to choke from stress? I'm running them at the moment over and over to see if I can get it to repeat the problem.

[mpociot]

Yeah, for some reason Herd was unable to properly restart FPM which causes the error to show up.

Some background explanation: Under the hood, the new dump interception feature makes use of a custom PHP extension. When the interception is disabled, we basically need to reload FPM to clear the opcache.

I'll fix this in the next update so that any FPM processes always get killed. Thanks for reporting this 👍

[andyunleashed]

Great stuff thanks for replying so quick with a fix and the planned update :)

[stevethomas]

FWIW, same problem and same fix worked for me.

Also when using "Force stop all", the Mails service is still running, so I had to then click "Stop all" to get that to stop before being able to "Start all".

[kevinpickett]

I am having the same issue today. (Mac, Herd 1.11.0 Build 33, PHP 8.3.11)

A few more details to add:

The force stop and start of services only resolves the issue if the network checkbox is unchecked. I am able to trigger the same issue again reliably 100% of the time, even after the force stop and start whenever checking/un-checking the network checkbox. I am making a GET request to a 3rd party service outside of my control. When the network checkbox in Herd is off, and I have performed a hard stop and start, the request appears to function and look normal. Then when the network listener is on, Herd appears not to like something with the response cookies.

[mpociot]

@kevinpickett when the network checkbox is checked, we add an event listener that listens for Http facade events - we don't actually modify anything on the outgoing request.

So you have an error as soon as you enable watching for outgoing http requests?

[kevinpickett]

@mpociot Yes exactly. That network request proceeds without issue when the network listener is turned off (which I wasn't able to do until I found this issue and performed the force stop +start). Looking at the stack trace, Herd seems to be looking for cookie data for the dump output that doesn't exist.

I was a bit confused at first, as I believe the stack trace is showing me Herd files for the network listener. If you checkout that screenshot above, you will the stack trace containing all of those frames from Herd. Trying to open those files is impossible, as they don't exist locally. Herd tries to take me to the following path in PHPStorm: phpstorm://open?file=phar:/Applications/Herd.app/Contents/Resources/valet/dump.phar/src/Watchers/HttpClientWatcher.php&line=44

[mpociot]

Ohhhh now I get it! This will be fixed in the next release - sorry if this caused any confusion.

[kevinpickett]

@mpociot No stress on my end, thanks Marcel! I just appreciate the heck out of what you all are building here 🙏🏻

[mpociot]

This is now fixed in Herd 1.11.1