本頁面說明使用 Cloud Tasks 時可能遇到的問題和限制。
執行順序
除了排定在日後執行的工作外，工作佇列的執行順序完全不受平台限制。系統不會保證或盡力以特定順序執行工作。具體來說，除非佇列完全清空，否則無法保證舊工作會執行。在許多常見情況下，較新的工作會比舊工作更早執行，且相關模式可能會在沒有通知的情況下變更。
重複執行
Cloud Tasks 嚴格實行「只執行一次」的機制。不過，如果必須在保證執行與重複執行之間進行取捨，採取保證執行的做法會導致服務發生錯誤，因此，系統確實會出現非零數量的重複執行作業。 開發人員應採取相關步驟，確保重複執行不會造成災難性事件。在實際工作環境中，超過 99.999% 的工作只會執行一次。
資源限制
立即處理佇列中之所以會有待處理作業，最常見的原因是目標執行個體的資源用盡。如果使用者嘗試在每秒只能處理 10 個要求的前端執行個體上每秒執行 100 個工作，系統就會建立待處理作業。這通常會透過兩種方式呈現，而增加處理要求的執行個體數通常可以解決這些問題。
輪詢錯誤與強制執行率
伺服器過載時，可能會開始傳回退避錯誤：HTTP 503 (適用於 App Engine 目標)，或 HTTP 429 或 5xx (適用於外部目標)。為回應這些錯誤，Cloud Tasks 會放慢執行速度，直到錯誤停止。這項系統節流機制可避免工作站過載。請注意，系統不會變更使用者指定的設定。
系統會在下列情況下進行節流：
Cloud Tasks 會針對所有錯誤進行退避。通常會使用
rate limits中指定的退避。但如果工作者傳回 HTTP429 Too Many Requests、503 Service Unavailable或錯誤率偏高，Cloud Tasks 就會使用較高的輪詢率。系統會考量Retry-AfterHTTP 回應標頭中指定的重試次數。為避免流量激增，並緩和流量突然增加的情況，當佇列剛建立或處於閒置狀態時，系統會緩慢增加調度次數；如果突然有大量工作可供調度 (因為建立工作率激增、佇列取消暫停，或許多工作排定在同一時間執行)，系統也會緩慢增加調度次數。
延遲時間遽增以及並行數量上限
伺服器負載過重也可能導致延遲時間大幅增加。在這種情況下，要求會維持開啟狀態較久的時間。由於佇列在執行時會受限於並行工作數上限，因此這可能會導致佇列無法依預期速度執行。如果受影響佇列所設定的 max_concurrent_dispatches 值過低，您可以提高該值，導入自訂頻率限制。不過提高 max_concurrent_dispatches 值無法解除任何根本的資源壓力。
長時間執行的工作發生升速問題
Cloud Tasks 佇列會根據先前調度成功的工作數量，逐步提高輸出量。如果工作處理常式需要相當長的時間 (以分鐘為單位) 才能完成工作並傳回成功回應，佇列的升速可能會延遲。
查看超過 5,000 項工作
如果工作超過 5,000 項，部分工作不會顯示在Google Cloud 控制台中。使用 gcloud CLI 查看所有工作。
重新建立名稱相同的佇列
如果從 Google Cloud 控制台刪除佇列，必須等待 3 天，才能重新建立相同名稱的佇列。這段等待期可避免在刪除或等待執行的工作發生非預期行為。此外，也能避免刪除或重新建立週期時發生內部程序失敗。