Questions: REST API - safe to instantiate a new Agenda at each received request? Every can handle only a single job at a time?

[Malv93]

Hi,
I'm using agenda package for the first time.

I'm building a REST API with Fastify, and I'm exposing an endpoint which is supposed to start running a job that is supposed to keep running at a given interval until some condition occurs.

I tried to follow the example in the agenda documentation. Therefore when a new request is made to my endpoint a new agenda is instantiated and it creates a new job that "runs at every interval".
All the jobs created in this way shares the same definition, but the attributes data passed to them change, and my goal is to keep as many of these jobs running as needed.

My main concerns are:

• is it safe to instantiate a new agenda at each request? Should I delete the agenda instances that I don't need anymore?
• does agenda override the previously created jobs at every new job run? The jobs share the same definition, and I don't understand this sentence that I am quoting in the docs of the every method

Every creates a job of type single, which means that it will only create one job in the database, even if that line is run multiple times. [Link to every documentationhttps://www.npmjs.com/package/agenda#everyinterval-name-data-options)

Many thanks for your help

[aarontravass]

Hey,
I am using Agenda in my company's production system and it's doing pretty fine. For context, our main Rest API server will schedule jobs dynamically and a pod in Kubernetes will run and process the job as defined.

is it safe to instantiate a new agenda at each request? Should I delete the agenda instances that I don't need anymore?

Yes! Agenda will pick up existing jobs from the database and match it with jobs that have been defined.

does agenda override the previously created jobs at every new job run? The jobs share the same definition, and I don't understand this sentence that I am quoting in the docs of the every method

It does not override previous jobs but rather checks the metadata and continues running them as required.

Here's a job that was defined a year ago in our dev system

{
"_id":{"$oid":"####"}
,"name":"####",
"type":"single",
"data":null,
"lastModifiedBy":"",
"nextRunAt":{"$date":{"$numberLong":"1709431200000"}},
"priority":{"$numberInt":"0"},
"repeatInterval":"*/30 * * * *",
"repeatTimezone":null,
"lockedAt":null,
"failCount":{"$numberInt":"2211"},
"failReason":"#####",
"failedAt":{"$date":{"$numberLong":"1709429400056"}},
"lastFinishedAt":{"$date":{"$numberLong":"1709429400056"}},
"lastRunAt":{"$date":{"$numberLong":"1709429400009"}},
"progress":null
}