Nats self publish a scheduled cron message?

[NOT-HAL9000]

I'm looking to publish a message to a stream at a certain interval.

I can set up a cron job and publish a message, however I'm wondering if it's possible (or planned) to be able to schedule a message to have the nats server self publish messages at set intervals? Basically a light implementation of cron jobs on top of jetstream.

Thanks

[derekcollison]

At this time you will need to figure out a way to publish yourself.

We have had folks use TTL of a stream with max deliver of 1 and advisory for when the message can no longer be delivered, but this seems contrived at the moment.

[drewcorlin1]

Would it work to do the following?

• Have an ackWait that is the difference between time of publishing and the desired delivery time
• On delivery 1 (using redelivery count) ignore the message and don't ack it.
• On delivery 2 actually do whatever you want to with the message.

[derekcollison]

Yes, that could work.

[ashupednekar]

Here's a POC based on this approach

https://github.com/ashupednekar/natshed

[Zetanova]

Beside KV, a managed job scheduler would be a great addition to nats.
It is nearly always required to also track job success / failure beside the response messages.

[jnmoyne]

You may want to take a look at https://github.com/choria-io/asyncjobs

[Zetanova]

yes, something like it, but without following:

• requires a separate process for the supervisor
• It uses the simple request/reply pattern. It breaks the NATS request/reply-many to _INBOX pattern.

Of course can the scheduling be done with an external protocol/process,
but it is a very basic feature for post applications like the KV store.

I only search for something basic like:

• schedule job A with message P in 10min to subject X.Y.Z NATS will then send this message in >10min to the subject as a Request/Reply but with a special durable _INBOX (Inbox on JS) and tagged with Job headers
• subscribe on job Athis will dequeue all response message (one or more) from the durable _INBOX tagged with Job headers
• get jobs regular request to get the status of current jobs

[ashupednekar]

I'd like to add this to rust, python, go... maybe through orbit or sth. Thoughts?

[neilalexander]

Think Orbit might be the right place for something like this, WDYT @Jarema?

[Zetanova]

Is this the place orbit repo ?

[tamis-laan]

Something like this would be sooooo helpful:

ns = await nats.connect("localhost:4222")

ns.cron.schedule("my_periodic_task_id", "*/1 * * * *", "my_topic",  "my message".encode())

ns.cron.schedule("my_one-shot_task_id", "2025-04-20T18:40:00+02:00", "my_topic",  "my message".encode())

ns.cron.remove("my_periodic_task_id")

When these tasks are one shot they should be automatically be removed after triggering and sending their message to the target topic.

[ashupednekar]

I have something similar at work, working pretty well. Any guidelines on what's accepted in orbit? Would this be okay... and what's the merge process like?

So you want a function to be invoked at the appropriate times, correct? Or is it just a scheduled produce call?

What I have is rust based, but discovers and invokes python functions, This would be different, so won't be a problem with my employer's OSS stance.

not sure how I'd go about the discovery part for static languages, let's see. If it's only produce, I can roll this out for go/rust in a week

Lmk if there's interest. Happy to hop on it

[ripienaar]

If we added a feature where if you put a message into a stream and it has - in a header - a cron like schedule that will cause republishes into the stream at that interval.

Would that be enough of a LEGO block for you to do what you want?

messages go into the stream so you could push consume for parallel concurrent schedule fires, pull consume for one-in-a-group doing the work etc.

Basically just the schedule timer as a service that would combine with our other features.

[ripienaar]

Yes I didn’t mention it but the draft design does have a single invocation only option.

[CVMarkBradley]

Is the mentioned draft design available to review anywhere and/or is there any progress/timeline on this that can be provided?

[MauriceVanVeen]

The design can be found here: nats-io/nats-architecture-and-design#350
The implementation for delayed messages is here: #7170
It will be released as part of a release preview pretty soon, otherwise our nightly builds should already contain all of this.

[CVMarkBradley]

Thanks.
Delayed messages is only one part of the design for this. Is there any information or timeline for the recurring/cron aspect of the design?

[ripienaar]

Maybe in the next release cycle - we release in 6 monthly chunks - but will see how prioritisation works out for that.