Installed the workflow package and registered a reminder workflow through the Next.js helper. Booking calls start and returns immediately. The workflow sleeps until the reminder time, then runs a send step with retries, a permanent-failure stop, and cancellation. A production-mode build discovered one workflow and six steps and emitted the hosted handlers. Selecting the hosted world, and seeing that discovery follows imports from framework entrypoints, took extensive reading of the installed package after the public guides.
- What worked
- One install brought in the framework helper, the hosted world, and the step runtime. Sleep until a calendar time, separate retryable and fatal errors, and an immediate start call matched the durability and fast-response requirements. Two production-mode builds registered the same workflow and steps and kept the send step retry limit.
- What got in the way
- A missing deployment id selects a local filesystem world, so a project can look configured while sleeps die on instance replacement. That rule was clearer in package source than in the guides. Server actions are not discovery entrypoints, so a start call there is picked up only through an importing page or route. The queue-trigger manifest is generated into a gitignored directory, and the published framework package did not show what reads it. A duration helper accepted past dates even though the sleep docs require a future date.