Temporal's determinism rule forces the three-day wait out of your Laravel job class

The rule barring the orchestrator from databases, external systems and random functions ^[1] serves a specific mechanical purpose, not a stylistic one. Nothing about coordinating steps needs it. It only makes sense if that function is expected to run more than once against a recorded history, with each `yield` resolving from something the server already knows. That is the mechanism behind the promise of guaranteed state progression ^[15]: the wait stops being a delayed job in Redis and becomes an event the cluster owns, and the PHP worker holding the process becomes disposable.

The two timescales in the sample show the seam. The workflow method yields `Workflow::timer(CarbonInterval::days(3))` ^[7]. The activity stub is constructed with a single option, `withStartToCloseTimeout(CarbonInterval::seconds(30))`, under a comment that calls it retry settings ^[6]. Three days is 259,200 seconds, so the orchestrator's shortest wait is 8,640 times the ceiling on one activity attempt ^[11]. That ratio is the point. Nothing in the worker needs to survive the gap, which is exactly the property the hand-rolled version lacks when a server reboots mid-process ^[14].

Adoption lands in two places. The runtime: a Composer install ^[4] plus a cluster for `TEMPORAL_ADDRESS` to point at ^[5]. The walkthrough does not cost that cluster out, and if Redis queues and supervisors are already handling millions of ordinary jobs for you ^[12], this is a second durable system rather than a replacement. The code: activities keep `User::findOrFail` and the `Mail` facade, resolved through Laravel's container ^[8], while the workflow keeps the timers and the branch ^[2]. Any existing job class that both sleeps and queries has to be cut along that line before it can move.

Then read the listing against the claim. Temporal is described as handling state persistence, timeouts, queryable statuses and complex retries ^[15]. The published code stops mid-identifier at `checkProfileS` ^[9], so the second timer and the sales-outreach escalation described in the flow ^[3] exist only in prose. Given the article's subject is keeping track of a user's progress through a flow, that gap is an ironic failure mode to leave hanging.

What would have to be true for this to transfer to your system: the requirement is that a single unit of work outlive a deploy, and a thirty-second email send falls well short of that bar. The seven days of elapsed waiting in this onboarding arc ^[10] cross at least one release, probably several, and every one of them is a chance to lose the row that says which step a given user reached. That is the threshold I would use, and it is narrower than the framing here suggests. The author's own opening concedes it: standard queues only start to show limits when the work becomes a multi-day, retry-sensitive state machine ^[13]. Below that line, the delayed dispatch you already run is cheaper than a new cluster plus a determinism rule you have to teach the team.