SchedulingDefault_spec.js fails with Node v6.8.0 (setImmediate problem)

[kirrg001]

We suddenly have a broken build https://travis-ci.org/TryGhost/Ghost/jobs/167170509.

grunt test:core/test/unit/scheduling/SchedulingDefault_spec.js fails on Node v6.8.0

The last job never get's executed, because setImmediate does not get triggered!

[kirrg001]

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#6.8.0
nodejs/node#8655

[kirrg001]

weird weird.

When i decrease the timeout diff from diff - 200 to for example diff - 70, then it works.
diff is the difference between the next job and now. And 200 tells the timer to wake up 200ms before, because setTimeout is not accurate.

So if the timeout get's invoked earlier to now, then it works?

https://github.com/TryGhost/Ghost/blob/master/core/server/scheduling/SchedulingDefault.js#L173

[marcuspoehls]

We’ve noticed the same kind of issue with post scheduling: if there are at least 3 schedules, the scheduler won’t publish (at least) the last one.

Used Setup

• Node.js: 4.5.0
• Ghost: 0.11.1
• Database: MySQL
• Steps to reproduce: local Ghost setup with post scheduling available, requires Ghost 0.9.0 or later. Then create 3 posts, schedule them with 11 minutes time difference and let the scheduler publish them. In our setup, the scheduler didn’t recognize the third post.

[kirrg001]

@marcuspoehls I can't reproduce what you are describing.

In our setup, the scheduler didn’t recognize the third post.

What do you mean by saying "didn’t recognize the third post"?
So you schedule the third post and then it remains in status "scheduled"?

[Fishrock123]

Node issue at nodejs/node#9084

[kirrg001]

@marcuspoehls Can you please contact me in our slack channel?
I am curious why you have problems on node 4.x.x 👍
This issue here describes a problem with node 6.x.x!

[marcuspoehls]

@kirrg001 Hi Katharina, sorry for the confusion. I found the actual issue: Ghost doesn’t pick up scheduled posts correctly after restarting the process.

Looks like while testing and reproducing the behaviour I didn’t let the process run continuously.

The init method of post scheduling loads already scheduled posts with the following filters:

• status:scheduled
• created_at:>=moment().subtract(7, 'days').startOf('day').toDate()
• created_at:<=moment().endOf('day').toDate()

That results in a options object like this:

{ context: { internal: true },
  from: Fri Oct 07 2016 02:00:00 GMT+0200 (CEST),
  to: Sat Oct 15 2016 01:59:59 GMT+0200 (CEST),
  filter: 'status:scheduled',
  columns: [ 'id', 'published_at', 'created_at' ] }

If there are already scheduled posts, they need to be created in between the from and to date range! Every earlier created post than the from date won’t get selected and never published through the scheduler.

Looks like the filter on from and to isn’t required at all?

[kirrg001]

@marcuspoehls yeah we can kill from/to filters and just fetch all scheduled posts you have left in the database 👍

[kirrg001]

Node 6.8.1 was released containing the fix.
https://github.com/nodejs/node/blob/v6.8.1/doc/changelogs/CHANGELOG_V6.md#6.8.1
Will test later and then close this issue 👍

[kirrg001]

It's fixed in 6.8.1!