Page MenuHomePhabricator

develop more detail plan on queue refactor for drupal upgrade
Closed, ResolvedPublic

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedNone

Event Timeline

The base consumer code is in Smashpig, so that shouldn't need to move anywhere. There are two other subclasses that most of the consumers share (WmfQueueConsumer and TransactionalWmfQueueConsumer) that could be moved to the wmf-civicrm Civi extension.

That might be the time to move over or reconsider our WmfException class too, as it's mostly used to classify types of failures and decide whether to send failmail and continue with queue processing or not.

Here are the notes I have so far about stuff to do, summarized from @Ejegg's comment above and from talking to @Eileenmcnaughton on IRC:

  • Instead of WmfException, use API_Exception.
  • Move concrete queue consumer classes somewhere in the wmf-civicrm Civi extension, maybe to CRM/Queue like here?
  • Fix formatting for Drupal norms (no tabs, two spaces).
  • Possibly refactor queue consumers to make them more Civi-y, and to have the consumer api less tightly coupled to the code that reads each message and modifies the database. For an example, again, see this patch.
  • Maybe add more tests?