AlejandroMorgante commented on code in PR #67524:
URL: https://github.com/apache/airflow/pull/67524#discussion_r3349559024
##########
providers/amazon/src/airflow/providers/amazon/aws/waiters/dms.json:
##########
@@ -95,6 +95,85 @@
"state": "success"
}
]
+ },
+ "replication_task_modified": {
+ "operation": "DescribeReplicationTasks",
+ "delay": 30,
+ "maxAttempts": 60,
+ "acceptors": [
+ {
+ "matcher": "path",
+ "argument": "ReplicationTasks[0].Status",
+ "expected": "modifying",
+ "state": "retry"
+ },
+ {
+ "matcher": "path",
+ "argument": "ReplicationTasks[0].Status",
+ "expected": "stopped",
+ "state": "success"
+ },
+ {
+ "matcher": "path",
+ "argument": "ReplicationTasks[0].Status",
+ "expected": "ready",
+ "state": "success"
+ },
+ {
+ "matcher": "path",
+ "argument": "ReplicationTasks[0].Status",
+ "expected": "failed",
+ "state": "success"
Review Comment:
Yes, in this waiter `success` means the async modification phase has
completed, not that the replication task is healthy/runnable.
DMS does not expose a separate `modify-failed` task state. If the
`ModifyReplicationTask` API call itself fails,
boto3 raises an error immediately before the waiter starts. Once the API
call is accepted, the task enters `modifying`, and this waiter only waits for
it to leave that state.
`stopped`, `ready`, and `failed` are all terminal states for that wait.
`failed` is included because users may modify a failed task to fix its
configuration, and the task can remain in `failed` until they explicitly
start/retry it afterwards.
So `failed` here means "the modification wait is complete", not
"replication succeeded".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
