Unexpected change in callback behaviour

Hi @ben-ryder,

This change was made because it's possible that downloading + applying the translated file will take more time than Webhook's response timeout. It's recommended to respond as quickly as possible otherwise webhook will retry (causing unexpected results) and eventually give up. We had such cases before, so we decided to implement this change again because we can't guarantee the download/apply time.

At that point why not check for updates just using cron?

Drupal cron does two things: runs cron hooks and then processes defined queues. TMGMT Smartling puts TMGMT Jobs into the download queue from two places: pushback controller (webhook) and cron hook (asking Smartling API for a list of translated files directly). So, if queues are processed independently (of Drupal cron) and frequently (by drush or Drupal console tools being triggered from external cron from the site hosting side) then there will be no delay in delivering translations by webhooks. I know people do this on Acquia and Pantheon hostings.

It would be nice to understand more about it before considering our options for the site in question.

I think, one of the possible options is not to rely on queue processing by Drupal cron and to run queue processing independently and more frequently.

Possible solutions may include adding the ability to configure if callbacks download immediately or add to queue

We will consider this option.

One other note, I feel it would have been great to communicate this change in the 9.13 release notes. I appreciate this is a bit of an edge case, but it would have been nice for it to be included just in case.

You're right. I've updated the release notes for 8.x-9.13 to avoid such a case in the future, thanks for pointing this out.

Hi @loparev, thank you so much for your thorough reply. It is really helpful and has cleared up the confusion I had.

Your explanation around why the change was made makes perfect sense, and your suggestion to consider processing the queues independently of cron is a really good one I'd not thought of.
My issue here was basically just that I was missing the context to understand the change and what the best options would be as a result, after reading your reply I'll likely look at queue processing over something like trying to get the old behaviour back.

Thanks again for you time and reply, much appreciated.