пакетом затяни в проект

чтобы было комильфо

это кстати топ фича

везде такую надо

а кстати, у меня этот скедулер актор не поднимается)

let schedulerRef = scheduleActor None   |> spawn mailbox "scheduler"
let schedule = Once <| DateTimeOffset.Now.AddSeconds(1.0)
 schedulerRef <! CreateJob (receiverRef, "receive", schedule)

сообщение сразу уходит в dead letter

коду 5 лет, вполне могло что-то поменяться

Мы уже года четыре Кварцом не пользуемся (возникли проблемы, когда переходили на кластер), перешли на Akka.Persistence.Reminders, который, кстати, Бартош написал, что и Акклинг. Если бы я по-прежнему использовал этот код, я бы что-то доделал, но когда сам не пользуешься, это трудно

Я помню, когда я сдался после перехода на кластер и убрал Quartz, переписав наш код, меня Василий Кириченко покритиковал, что, мол так опенсорс не работает, надо потратить время и все починить. Он в принципе прав, но у нас там буквально рушился продакшн, не было времени на долгое расследование. Akka.Persistence.Reminders в кластере сработал чисто с самого начала.

Я ни в коем случае не утверждаю, что Akka.Persistence.Reminders _лучше_, чем обертка над кварцем, кварц  известен и вне Акки, а Бартош свою библиотеку написал конкрентно под Akka.NET, к тому же судя по тому, как он сейчас сопровождает Акклинг, если там что возникнет, исправлений можно ждать долго.

спасибо за обширный ответ. попробую разобраться как из под фарша поднять ремайндер.

Ну там все просто. Это ведь по сути отложенное сообщение, там все более идиоматично с точки зрения модели акторов. Моменты, которые надо учитывать:
- Быть осторожным с сообщениями, которые откладываются на длительное время. Если за это время поменяется тип сообщения, то reminder не сможет его десериализовать. Поэтому мы типы отложенных сообщений у нас предельно простые: только поля встроенных типов. Никаких там DU или полей типа record
- Поскольку Akka.Persistence.Reminders хранит отложенные сообщения как стейт персистентного актора, то если возникнет проблема п.1, то он не сможет поднять весь стейт. Это может стать катастрофой, если есть какой-то один reminder, который отвечает за все отложенные сообщения. Поэтому лучше заводить reminder на каждый тип сообщения

проблема с восстановлением стейта при смене схемы не эксклюзивная для reminder, а общая для персистентных акторов и всего евент-сорсинга так-то.

Да, конечно. Просто когда это мой персистентный актор, я об этом знаю и помню. А тут легко упустить

у меня проблема попроще)
Reminder.ScheduleRepeatedly требует наличие ActorPath, а такой проперти нет у IActorRef

Вот для примера, так мы стартуем ремайндер в кластере

let private startReminder (system:ActorSystem) reminderId role =
       system.ActorOf(
           ClusterSingletonManager.Props(
               Reminder.Props(ReminderSettings.Create(system.Settings.Config).WithPersistenceId(reminderId)),
               PoisonPill.Instance,
               ClusterSingletonManagerSettings.Create(system).WithRole(role)),
               reminderId)
       |> ignore

А так создаем прокси

let private createReminderProxy (system : ActorSystem) reminderId role : IActorRef<Reminder.Schedule> =
       let proxy =
           system.ActorOf(
               ClusterSingletonProxy.Props(
                   sprintf "/user/%s" reminderId,
                   ClusterSingletonProxySettings.Create(system).WithRole(role)),
                   sprintf "%s-proxy" reminderId)
       typed proxy

А как еще он будет знать, куда посылать сообщение?

можно было наверное ICanTell принимать вместо пути ещё

Не уверен. Reminder живет самостоятельной жизнью. У него нет никаких ссылок на другие акторы изначально

хм, ну да. Путь строкой наверное самый норм вариант для такого dormant state, который может днями жить

Я когда-то пути до акторов типизировал аналогом String-enum (тогда ещё писал на C#)