У меня есть рабочий sidekiq, который ожидает изменения записи, сделанной удаленным клиентом. Что-то вроде следующего:

 #myworker async process to wait for client to confirm status

 perform(myRecordID)
   sendClient(myRecordID)
   didClientAcknowledge = false
   while !didClientAcknowledge
    didClientAcknowledge = myRecords.find(myRecordID).status == :ACK_OK
    if didClientAcknowledge 
      break
    end
    # wait for client to perform an update on the record to confirm status
    sleep 5.seconds
   end
   Rails.logger.info("client got the message")
end
   
  

моя проблема в том, что, хотя я вижу, что клиент фактически выполнил подтверждение и обновил запись с правильным обновлением статуса (ACK_OK), мой поток sidekiq продолжает видеть старый статус для MyRecord.

Я уверен, что моя логика здесь ошибочна, но похоже, что процесс sidekiq не «видит» изменения в БД … но если я использовал свою консоль rails, я вижу, что клиент фактически обновил БД, как и ожидалось…

Спасибо!

Редактировать 1

хорошо, вот мысль, вместо цикла я запланирую еще один вызов рабочему в течение 5 секунд … итак, вот обновленный код:

 perform(myRecordID, retry_count)
   retry_count -= 1
   if retry_count < 1
      return
   end
   sendClient(myRecordID)
   didClientAcknowledge = false
   if !didClientAcknowledge
    didClientAcknowledge = myRecords.find(myRecordID).status == :ACK_OK
    if didClientAcknowledge 
      Rails.logger.info("client got the message")
      return
    end
    # wait for client to perform an update on the record to confirm status
    myWorker.perform_in(5.seconds)
   end
   Rails.logger.info("client got the message")
end
  

Кажется, это работает, но будет тестироваться немного дольше .. одна из проблем заключается в подсчете повторных попыток, что означает, что мне нужно поддерживать какую-то переменную между вызовами worker…

edit2 возможно, это можно сделать, передав время первому вызову, а затем проверив, превышен ли тайм-аут перед вызовом следующего экземпляра … предполагая, что время не стоит на месте и внутри асинхронного вызова…

edit3 Добавление аргумента retry_count позволяет нам контролировать, сколько раз этот рабочий будет порожден…