Currently the plugin is only designed for a long-running, single-server environment. Need to support the following cases:
multi-instance (eg load balanced)
ephemeral servers (ie lambda for payload v3) -- lower priority since v3 is still in beta
For ephemeral envs, the plugin should expose a new option like useCron so the consumer can disable the onInit cron behavior. And, should export the init#scanner and lib fns in a way that they can be easily plugged into an API route that can be pinged externally. Last, will need to ensure that eg with a 15min window, a post scheduled for 10:15 will be scheduled at the top of the 10:15-10:30 window (rather than the end of the 10-10:15 window) .
Multi-instance is a little tricker, probably needs several steps:
Wrap the entire scan / schedule / publish flow in a transaction
Add a new scheduled_posts.status like scheduled for posts that have actually been scheduled, exclude them from getPostsToBeScheduled find op
accept a fn through plugin config that allows consumers to hook into / abort the scan / publish operation (ie for a leader/follower setup)
Currently the plugin is only designed for a long-running, single-server environment. Need to support the following cases:
For ephemeral envs, the plugin should expose a new option like
useCron
so the consumer can disable theonInit
cron behavior. And, should export theinit#scanner
andlib
fns in a way that they can be easily plugged into an API route that can be pinged externally. Last, will need to ensure that eg with a 15min window, a post scheduled for 10:15 will be scheduled at the top of the 10:15-10:30 window (rather than the end of the 10-10:15 window) .Multi-instance is a little tricker, probably needs several steps:
scheduled_posts.status
likescheduled
for posts that have actually been scheduled, exclude them fromgetPostsToBeScheduled
find op