[wp-trac] [WordPress Trac] #63987: wp_get_scheduled_event() incorrectly returns false for cron events scheduled with a timestamp of 0.

[WordPress Trac]

#63987: wp_get_scheduled_event() incorrectly returns false for cron events
scheduled with a timestamp of 0.
-------------------------------------------------+-------------------------
 Reporter:  codekraft                            |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:
Component:  Cron API                             |     Version:
 Severity:  normal                               |  Resolution:  wontfix
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info 2nd-opinion close                         |
-------------------------------------------------+-------------------------

Comment (by codekraft):

 Hi @mindctrl and @audrasjb,

 Thank you both for reviewing this and taking the time to discuss it! And
 sorry it took me so long to reply... if what I’m saying is nonsense,
 please don’t even bother taking it seriously. I completely understand the
 reasoning, but I would kindly ask you to reconsider closing the ticket, as
 I have just encountered a real-world case where a client's site was broken
 by this exact issue.

 Regarding the point that **"Events with a zero timestamp cannot be
 registered using public functions"**, this is actually **possible**
 through `wp_schedule_event()` due to a PHP quirk with floating-point
 numbers.

 Here is how it happens using public functions:
 1. If a third-party plugin accidentally passes a float between 0 and 1
 (e.g., `0.5`, maybe due a wrong calculation), the validation `!
 is_numeric( 0.5 ) || 0.5 <= 0` evaluates to `false`. The error check is
 bypassed.
 2. The event is passed to the core system to be saved.
 3. When WordPress sets this in the multidimensional cron array, PHP
 automatically truncates the `0.5` float key into an integer `0`.

 **The Real-World Problem:**
 While cron events are indeed meant for future dates, bugs in third-party
 plugins happen. When a plugin accidentally triggers the float loophole
 above, the event gets registered at `0`. Once it is stuck at `0`, we enter
 a "cul-de-sac" and it becomes impossible to delete the event using
 standard public functions like `wp_unschedule_event()`.

 The site gets permanently stuck with a ghost cron job that cannot be
 cleared normally, forcing manual database intervention on the `cron`
 option.

 Casting the timestamp to an `(int)` before validation in the core, or
 using `is_int()`, would prevent this unrecoverable state from happening in
 the first place.

 Would you be open to reopening the ticket to patch this edge case? thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63987#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform