Version Control and State (schedules)

  • We have recently moved from a Postgres store to a File-System store, so that we can store and deploy all of our reports from version control. We develop new templates in a local docker container, and re-deploy periodically. This has worked well, except for one issue. The problem is that many of the schedules are being sent right after de-deploy, since we commit the local state of schedules stored in the data/schedules file, and that overwrites the state on the previously running instance. So on deployment, it seems the CRON logic thinks that many schedules are over due from their last run time.

    I am wondering if this issue has been solved before, and if there are any recommendations.


  • This is a duplicate of this

    You can install the scheduling extension from the master

    npm i jsreport/jsreport-scheduling --save

    and use config


    to skip schedules that are overdue more than 5 minutes

  • Adding the following lines to the jsreport.config.json did not work. Overdue schedules were still being sent out.

        "extensions": {
            "scheduling": {
                "misfireThreshold": 300000 

    I suspect it might be because we are currently using the jsreports/jsreport:2.6.1-full image. It looks like it was last updated ~2 months ago, and the scheduling fix was added only ~1 month ago. I tried adding npm i jsreport/jsreport-scheduling to the Dockerfile hoping that it would use the updated scheduling package, but it still didn't work.

    FROM jsreport/jsreport:2.6.1-full
    RUN npm install \
            jsreport/jsreport-scheduling \
    	dotenv \
    	moment \
    	nodemailer \
    	numeral \
    WORKDIR /app
    COPY jsreport.config.json ./
    COPY data ./data/

    Several questions:
    A) Do you think my explanation for why it's not working is correct?
    B) Will there be an updated docker image soon?
    C) Would you recommend using a node:alpine image and installing each package/version explicitly?

  • A) Do you think my explanation for why it's not working is correct?

    I think I get it right

    B) Will there be an updated docker image soon?

    Likely in January will 2.7.0 be ready. However, I think it is pointless, you should be able to build your image, and your dockerfile looks fine.


    It is better as you have it now.

    I was trying to replicate your problem, but it works fine for me. Please check my steps and try to find out what is the difference causing the problem.

    1. Create normal folder with jsreport app
    2. Start jsreport, create a schedule with one-minute interval and stop jsreport
    3. Wait a few minutes
    4. Add to the jsreport.config.json misfire config which throws away tasks delayed by 30 seconds
        "extensions": {
            "scheduling": {
                "misfireThreshold": 30000
    1. Create the same Dockerfile as you have it and build docker image
    2. Run docker image
    3. Check the logs, you should see max one job running.

  • So I followed your instructions in a fresh testing repo and it worked as expected (over-due schedules being detected as misfires).

    After a while (way too long...) of being perplexed why our own JSReports repo was not detecting misfires, I wondered if Docker was somehow caching the modules. I did a docker-compose down command, and afterwards over-due schedules were detected as misfires.

    Side note - the logs showed:
    info: Using extension scheduling@github:jsreport/jsreport-scheduling#0a6b8c39577c829b525a82078691d4f100426ee5
    when that extension seemed to not actually be used, which was confusing.

    Thanks for your help,

    Info about docker setup, for reference/posterity.

    version: '3.3'
        build: ./
          - 5488:5488
          - extensions_fsStore_syncModifications=false
          - extensions_fsStore_sync_usePolling=false
          - ...


    version: '3.3'
    #Override file will run by default if not excluded or -f is not included at local runtime.  This is standard docker-compose behavior
    #for local branch, docker compose will look different, attaching the local volume:  Want to keep the file system files updated for version control.
          - ./data:/app/data

Log in to reply
