Feature request: Effect.Process.spawn/kill + actual sleep delay simulation

[CharlonTank]

Context

I'm building a Lamdera app with scheduled tasks (rent creation on specific dates, ticket reminders after 3 days of inactivity). These tasks can be cancelled/rescheduled.

Current Behavior

1. Sleep delays are ignored in tests

In Effect/Test.elm (lines 3857-3859):

SleepTask _ function ->
    -- TODO: Implement actual delays in tasks
    runTask maybeClientId state (function ())

All sleeps execute immediately when the command is created, ignoring the duration.

2. No way to cancel in-flight sleeps

Effect.Process only exposes sleep, not spawn, kill, or Id from the standard Process module.

When I reschedule a task:

1. I remove it from my scheduledTasks dict
2. I create a new Effect.Process.sleep command
3. But the previous sleep is already "in flight" and will still fire

This creates many phantom messages that I have to filter out in my handler.

Proposed Solution

Phase 1: Implement actual sleep delays

Track pending sleep tasks with their scheduled execution time. When fastForward or wait advances time past a scheduled sleep, execute it.

Phase 2: Add spawn/kill support

module Effect.Process exposing (sleep, spawn, kill, Id)

spawn : Task x a -> Task y Id
kill : Id -> Task x ()

This would allow properly cancelling scheduled tasks.

Workaround

Currently I check task validity when ExecuteScheduledTask fires:

executeTask taskId expectedTime model =
    case Dict.get taskId model.scheduledTasks of
        Just entry ->
            if entry.scheduledAt == expectedTime then
                Just ( entry, { model | scheduledTasks = Dict.remove taskId model.scheduledTasks } )
            else
                Nothing  -- Task was rescheduled, ignore
        Nothing ->
            Nothing  -- Task was cancelled, ignore

This works but creates noisy test output with many phantom messages.

Questions

1. Is implementing actual sleep delays on the roadmap?
2. Would spawn/kill make sense once delays work?
3. Happy to help with test cases or contributions if useful!

Thanks for the amazing library! 🙏

[MartinSStewart]

I happen to be in the middle of implementing simulated delays for sendToBackend, sendToFrontend, sendToFrontends, and broadcast. Adding that same support for Effect.Process.sleep should be doable.

As for spawn/kill, my understanding is that they don't work with normal tasks? I'm not sure about this, I haven't tried using them but my understanding is that they are intended for effect packages, though even then I'm not sure if any effect package uses them.

[CharlonTank]

Thanks for the quick response! 🙏

Great to hear you're already working on simulated delays!

Actually, let me clarify - kill is the main thing I need, not just the delays.

My use case: I send a reminder 3 days after the last message in a chat. Each new message should cancel the previous reminder and schedule a new one. Without kill:

• Message 1 → schedules sleep for 3 days
• Message 2 → schedules another sleep for 3 days (can't cancel the first)
• Message 3 → schedules another sleep
• ... × 50 messages = 50 sleep processes that will ALL fire

In production, that's 50 ExecuteScheduledTask messages where only the last one is valid. I have to filter them out in my handler, but it's still unnecessary processing and forces me to maintain validation logic.

Being able to kill a sleep would let me properly cancel the previous reminder before scheduling a new one.

What would you do in my position?

[MartinSStewart]

I would have a Time.every subscription that runs perhaps every hour. The BackendModel tracks the last time a reminder was sent and checks if it's time to send another reminder. This has the advantage that if your backend app were to crash or restart for some reason, it doesn't forget what reminders still need to be sent.

[CharlonTank]

Ok I see, I used to do that but then, since I'm testing my app for 5 years, it became impossible because too many hours in 5 years x)
About the backend app were to crash or restart, I have a scheduler that does that can restart the processes already.