I got this one. ??
$schedules comes from wp_get_schedules, as you know. It’s a list of possible times.
One of the original incarnations of the WP Cron system allowed you to hook callback functions directly to the schedules list. You still can, technically, with the cron_schedules filter. As you can imagine, this wasn’t the greatest method and didn’t make things easily expandable, so it was dropped in favor of calling actions instead of functions, which works much cleaner. But if any old code is still using it, it still will call it. Core contains no callbacks on the schedules, and I’m fairly certain that no commonplace plugins use it. So yes, that is kind of dead code.
Now, note that spawn_cron will be called only if there are scheduled events that need to run, thanks to the if ( $timestamp > $gmt_time ) break; line.
Now, on to spawn_cron itself.. No, it should not exit or die, because it’s not actually sending a redirect in most circumstances. You’re only reading the first part. That first part only happens if ALTERNATE_WP_CRON is defined to true. That’s sort of a backup plan, for systems that have specific issues. The main method is below that big if block.
The main method is that it builds that big $cron_request array, then calls wp_remote_post to the wp-cron.php file. This triggers the wp-cron.php process to start, in another web request. Note that the timeout is set to 0.01, which is not enough time for anything to happen, so the request is sent, dropped, and then the function returns and the page continues to generate for the viewing user. An exit here would mean the user sees a blank page.
For the ALTERNATE_WP_CRON case, the process cannot end here, because this request changes into the one that includes wp-cron.php, and the viewer gets redirected to essentially the same page they requested, in a different process. You could argue that having it exit() instead of return after the include_once makes sense, but that assumes that the user actually got redirected, than wp-cron.php returned instead of exiting, that wp-cron.php didn’t actually just hit the PHP process timeout (cron events can take a while), etc. If for whatever reason the wp-cron.php doesn’t do the job and/or the user didn’t redirect, then you still want to try to serve them the page. It may be too late by that point, and it’s a bit of extra work, but it’s worth a shot.
Realistically, nobody should be using ALTERNATE_WP_CRON anyway. That case is only for when a server cannot make a request back to itself, for whatever reason. There’s a few of those reasons, but generally this is a misconfigured server, or it’s some poor attempt at making a server “secure”. The only time I recommend it is when people have problems with “Missed Schedule” on posts. It doesn’t come up a lot.
