[v2] sync command doesn't fail immediately when SSO token expires

[borrell]

When executing an S3 sync with an SSO profile, if the SSO token expires during the sync (e.g. expires via timeout), then the sync will continue, trying each file and displaying an error noting that the token has expired.

aws2 sync --profile SSOProfileName docs/ s3://example.bucket/backups

upload: ../docs/file1.txt to s3://example.bucket/backups/file1.txt 
upload failed: ../docs/file2.txt to s3://example.bucket/backups/file2.txt The SSO session associated with this profile has expired or is otherwise invalid. To refresh this SSO session run aws2 sso login with the corresponding profile.
upload failed: ../docs/file3.txt to s3://example.bucket/backups/file3.txt The SSO session associated with this profile has expired or is otherwise invalid. To refresh this SSO session run aws2 sso login with the corresponding profile.
upload failed: ../docs/file4.txt to s3://example.bucket/backups/file4.txt The SSO session associated with this profile has expired or is otherwise invalid. To refresh this SSO session run aws2 sso login with the corresponding profile.
...

I would imagine (without entirely thinking through any possible side-effects) that the desired behaviour would be for the sync to fail immediately, rather than continue retrying.

[klaytaybai]

Hi @borrell, thanks for your feedback. Instead of failing immediately, do you think retrying the current file and not attempting all others would be a preferred behavior?

[borrell]

Retrying the current file would be fine, to a point (see #3 below!)

I've got a few more thoughts, after ruminating on it for a day:

1. The main issue I see is that it leaves the action in a potentially inconsistent state. For example, If I kick of a sync command, and part-way through the SSO token times out, without a separate reconciliation process to determine which files have been synchronized, there's no easy way to identify which files failed to be synchronized (particularly if you run the command as part of a script, and/or have a log file a million lines long).

2. I initially tagged this as a V2 issue, however I don't know what the behavior is for V1 (or V2 for that matter) if you are using temporary IAM credentials, that could also expire partway through the command. It would be worth investigating if it fails in the same manner, or if it behaves differently.

3. As noted above, retrying the file is acceptable, however I'm not sure of the intention for this. It is possible that the token may be refreshed (i.e. a user using a separate terminal to run an 'aws2 sso login' to refresh the token), but outside of that it's not a transient error - it won't recover without some sort of user intervention. In that case, retrying the file won't have any chance of succeeding. The retry would need to have an upper limit (so as not to get stuck in a locked state), and unless the user is sitting there ready to refresh the token, retrying the file once or ten times won't have a difference.

4. If the command aborted with an indication that the credentials were expired, then it would allow error handling that condition in a script or tool (e.g. detecting that the command aborted due to failed credentials, refreshing them, and retrying).

[klaytaybai]

Good points. Thanks for the feedback

[mlopezantequera]

Perhaps these should be options for the client.

In my application, a wrapper script can request a new token and retry the sync.

Sadly the sync only returns after attempting the whole sync (even though the token has expired). This means a lot of time is wasted scanning the source files.

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.