Open mingard opened 7 years ago
Shouldn't this be handled by Queue? /cc @orinocai
@eduardoboucas Currently yes, but potentially not in the future, depending on roadmapped decisions around the remit of api. @josephdenne @jimlambie thoughts?
I was under the impression that our messaging queue piece would be the long-term solution for handling this type of thing, as it should elegantly solve issues of concurrency/locks that would arise from having multiple instances of API.
There should not be a dependancy on Queue for simple tasks such as publishing on a specific date: the overhead is unnecessarily high. Document-level tasks should be handled by API.
Issue
There exists a piece of logic within DADI/publish which stores scheduled document changes (publish, unpublish etc) and makes requests to API at the appropriate time.
In order to move this logic out of publish and into API, the task must be handled through a hook.
Suggested options
Using a timeout The issue with this method is that a timeout will be destroyed if the app crashes or is intentionally restarted.
Child process A child process would continue, but would not remain in sync with any process callbacks. It would also fail if the core app was offline.
Scheduling collection A scheduled task queue could be read on boot and used to build timeout events.
Scheduled tasks would always be stored as a request body and timestamp.
When a new scheduled task is created, a timeout would be created and the task would be stored in the scheduling collection for persistence through exit.
The same queue could be used to handle system protective strategies at peak load by pacing DB PUT/POST/DELETE requests.