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
const oneDayAgo = new Date(Date.now() - 1000 * 60 * 60 * 24);

export const jobThatExecutes = () => {
// job here that uses it
}
const oneDayAgo = new Date(Date.now() - 1000 * 60 * 60 * 24);

export const jobThatExecutes = () => {
// job here that uses it
}
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
kapa.ai
kapa.ai3mo ago
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:
export const jobThatExecutes = () => {
const oneDayAgo = new Date(Date.now() - 1000 * 60 * 60 * 24);
// rest of your job logic
}
export const jobThatExecutes = () => {
const oneDayAgo = new Date(Date.now() - 1000 * 60 * 60 * 24);
// rest of your job logic
}
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?
CamBlackwood
CamBlackwoodOP3mo ago
@kapa.ai that confirms my suspicion. Thanks kapa!
kapa.ai
kapa.ai3mo ago
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?

Did you find this page helpful?