2 個答案
- 最新
- 最多得票
- 最多評論
0
Hmm, very interesting. I hadn't considered using a separate state machine like this. Looks nice, I'll definitely investigate!
I can't see why they didn't carry the waiter architecture forward more quickly but in the interim I stuck a blocking poll every 0.2s ... feels hacky but it works until I find a better way :)
Thanks,
David
已回答 9 個月前
0
The best way to handle this would be to move the workflow logic into AWS Step Functions. Here is an example state machine which submits a job, waits, polls for job status, then waits again if needed. Step Functions will give you built-in error handling and retry capabilities.
See Serverless Workflows Collection for more examples and templates
已回答 9 個月前
相關內容
- 已提問 6 個月前
- AWS 官方已更新 2 年前
You could absolutely place the wait within your function but while the code pauses you're still paying for the function's execution cost. (see Synchronous waiting)
Any reason not to manage function configuration changes through CI/CD? https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-deploying.html