Multiple Effect.timers with the same id?

[DavidKmn]

My question is regarding running Effect.timers with the same id and which of the outcomes out of the below 3 do we expect and can this be changed (or do we have to write our own TCA extensions to manage other cases not handled).

1. each new timer effect cancels the previous one with the the same id
2. if a timer effect with a repeating id already exists then the new timer with the same id just gets ignored (ie idempotency)
3. we can have all of these timers running with the same id, and when we cancel with the id using Effect.cancel then all of the timer effects with this id get cancelled

[andreyz]

Short answer: 1. No. 2. & 3. Yes.

Long answer:

So the Effects.timer is just a wrapper around Timer Publisher with a .cancel

public static func timer<S>(
    id: AnyHashable,
    every interval: S.SchedulerTimeType.Stride,
    tolerance: S.SchedulerTimeType.Stride? = nil,
    on scheduler: S,
    options: S.SchedulerOptions? = nil
  ) -> Effect where S: Scheduler, S.SchedulerTimeType == Output {

    Publishers.Timer(every: interval, tolerance: tolerance, scheduler: scheduler, options: options)
      .autoconnect()
      .setFailureType(to: Failure.self)
      .eraseToEffect()
      .cancellable(id: id)
  }

And from looking at cancellation source code you'd notice that Hashable id is used as a key to a dictionary of arrays with effects cancellations, hence same id will add the effect to the same key and will cancel all at once once requested.

There might be subtle differences with cancelsInFlight: parameter, but you'd probably best read about it in the source comments.

[stephencelis]

@dannyhertz actually brought this up recently. @mbrandonw and I are thinking that Effect.timer's cancellation should also pass the cancelInFlight: true action, which would make "1" change to "Yes". We think this is probably the most correct default behavior, as multiple concurrent timers for the same id doesn't seem to make sense.

[DavidKmn]

@stephencelis I think is right about the idea of introducing a cancelInFlight for a timer. We have had to manage this behaviour in 1, since this is what we wanted. Any thoughts on release dates?

[dannyhertz]

Here's the PR! #536