Time-out in ContextUploader

@loparev,

We still run into these issues today. Correct responses are received, with content like this:

    [processUid] => 3107a0c4-954d-4db5-ac48-ae07f0e8f598
    [processState] => IN_PROGRESS
    [processType] => MATCH_CONTEXT
    [createdDate] => 2025-09-10T14:10:46Z
    [modifiedDate] => 2025-09-10T14:10:46Z
    [result] => Array ...

Until it switches to state COMPLETED, so the functionality works as designed but it sometimes just takes to long. We tried increasing the time-out to 30 seconds, but it still happens to often. I'll try to capture some of the problematic process ID if you can use those the check logs or something?

Is it really necessary to wait for the matching to complete processing? Edit: If I read the code correctly the response is only used to log a message? I assume it's enough to wait for the upload to complete and continue on Drupal's side?

From time to time queue items are building up rapidly because a lot of translations are being requested (campaign season for our client). We already disabled cron processing to not disturb other processes. See https://www.drupal.org/project/tmgmt_smartling/issues/3545995

@loparev,

We've read the code and understand that this is the flow that needs to be followed, but what's the benefit of waiting on the Smartling matching process to finish? In our case we already increased the timeout to 30 seconds, and even then it's sometimes not enough.

Is there other functionality depending on these processes to finish correctly? Or is it only a log that needs to happen on Drupal side?

To prevent locking the process: isn't it possible to do the upload, capture the processUuid from contexts/upload-and-match-async and put that in another queue so we can use DelayedRequeueException to "wait" for the process to finish?

The only thing I want to prevent are timeouts and errors in our logs. These are caused by uploadAndMatchContextSync because it uses the wait method to check status of the (slow?) matching process on Smartling side.

That's why I would split the functionality up in 2 steps/queues but keep all existing logic, that way we give Smartling the time it needs to finish processing without failing on our side:

1. trigger uploadAndMatchContext, retrieve the processUid and create a new item in a separate queue
2. • queue worker uses DelayedRequeueException instead of waiting in the PHP process itself
   • when process is finished, fetch all information using uploadAndMatchContext again and log messages
   • trigger (improved) uploadContextMissingResources

The major difference it that the waiting part is not done in PHP but in a queue with the correct exceptions, that won't block the queue. Processing of other queue items will continue while waiting for slow ones.

Part of my comment here https://www.drupal.org/project/tmgmt_smartling/issues/3546398 is related to this topic as well:

I think uploading all of these assets one by one also makes the process incredibly slow. Why not use Guzzle http client instead of curl commands directly after which you could easily execute async upload commands for all of those assets: https://docs.guzzlephp.org/en/stable/quickstart.html#concurrent-requests