Possible unexpected caching in Jobs?
I have a job running every 5 minutes, checking for a row that hasn't been updated in the last 24 hours
At the top level of the file i.e. NOT in the job function, I define it as such
I can see in my logs that it currently evaluates "one day ago" as 16th June, when today is 18th June - and the last updated row is evaluating to 17th June (30 hours ago from now), meaning it should be updated if the one day ago is correct - which it appears not to be.
I am going to try and updated it now to move the 24 hours ago variable into the function itself, but wanted to check what default behaviour was, and have this asked in case people search for the future!
3 Replies
Hi @CamBlackwood. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're encountering a classic JavaScript (and general programming) pitfall, not something specific to Wasp or its job system.
When you define a variable like
const oneDayAgo = new Date(Date.now() - 1000 * 60 * 60 * 24);
at the top level of your module (outside the job function), it is evaluated only once—when the module is first loaded. In the context of Wasp jobs (which use pg-boss as the executor), your job handler function will be called repeatedly, but the top-level code is only run once when the server process starts or reloads. This means oneDayAgo
will always have the same value for every job execution, regardless of when the job actually runs.
To ensure oneDayAgo
is always relative to the current time when the job runs, you should move its calculation inside the job function:
This way, every time the job runs, oneDayAgo
will be recalculated based on the current time.
There is no Wasp-specific caching or job execution behavior that would cause this—it's just how JavaScript modules and function scopes work. Wasp jobs are executed by pg-boss, and your job handler is called fresh each time, but any variables defined outside the handler will not be re-evaluated per run. For more on how jobs are executed in Wasp, see the docs on Job Definition and Usage and pg-boss considerations.
So, your fix (moving the variable inside the function) is the correct approach!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai that confirms my suspicion. Thanks kapa!
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're welcome! Your understanding is correct—defining variables like dates at the top level of a module will only evaluate them once when the module is loaded, not each time the job runs. Moving the calculation inside the job function ensures it uses the current time on every execution.
While the knowledge sources do not explicitly discuss this specific scenario with job scheduling and variable scope, there is no indication of unexpected caching behavior in Wasp jobs. The behavior you observed aligns with standard JavaScript module evaluation and is not unique to Wasp.
If you have more questions about Wasp jobs or encounter other issues, feel free to ask!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?