Refactor ContentItem State (Published/Draft/etc) System

[toastercup]

The logic for the current ContentItem State system is brittle, mostly hardcoded and must be completely rebuilt. There are several avenues we can take, including:

• Using a library such as https://github.com/hired/reactor to schedule/subscribe to state change events via Sidekiq. There's several downsides to this:
  • If a user updates the state-change-to-be-scheduled once, then does it again, the old state change event has to be removed from the queue and recreated
  • To ensure job durability, several changes must be made to Sidekiq's config (so that the job is not removed from Redis once it's passed to Sidekiq): https://github.com/mperham/sidekiq/wiki/Reliability
  • There's no explicit guarantee a task will succeed once it's sent to a queue.
  • If the job signature or body changes due to a code redeployment, scheduled events may no longer function. To avoid this, the job must be deprecated but remain in the codebase, and a new job created until the old one can be safely removed. This may lead to some amount of bloat.
• The best approach may be to calculate state dynamically. This is easy enough to do in Ruby - we already do this in the current, messy implementation. However, this becomes trickier in the world of ElasticSearch, where our indices will not reflect these changes to state unless Rails manually informs/updates it. This is entirely possible, but the best approach would be to use ElasticSearch Aggregations. This would require that most of our dynamic query infrastructure be built out, however.

It's my belief that dynamic state calculation at runtime and ElasticSearch Aggregations are the most reliable, maintainable approach. It will be more difficult to implement at the outset, but we'll have a much more solid foundation to work from. I'll be digging further into this as time goes on, and will update this thread with more details as we reach a decision.