A production bug needs a fix today. Two approaches are on the table — which one?

The deciding factor is the hard deadline: the production bug must be fixed today, and only the guard-at-the-input approach satisfies that requirement — it can ship within the hour, whereas the scheduler rework slips to tomorrow and leaves users exposed to ongoing damage for another 24+ hours. From an incident-response standpoint, the priority is minimizing customer impact and time-to-resolution by stopping the bleeding first: a narrowly scoped guard at the boundary where the bad input enters stabilizes the system quickly while leaving the underlying design and all downstream code paths untouched, which keeps the blast radius small and the regression risk low when validation time is scarce. By contrast, the root-cause fix, though technically superior because it eliminates the entire class of bug, requires modifying the scheduler — the hot path that everything runs through. Making a structural change to such a high-impact component under time pressure, without adequate testing and roll out controls, could easily convert one production bug into several. The urgency of the mitigation should also be decoupled from the complexity of the root-cause analysis, rather than forcing a high-risk change during an active incident. Importantly, the two approaches are not mutually exclusive: the correct sequence is to ship the guard now as a targeted mitigation, verify stabilization, and then deliver the scheduler fix as a properly tested fast-follow with staged rollout. Judged against the actual requirement (fix today) and risk-adjusted quality under tight time constraints, the guard is clearly the better choice.