Concurrent assume runs fail to write the shared SSO token to the keychain (-25299)

[teake]

Issue Description

When several assume processes run at the same time (e.g. a script running a command across many accounts), nearly all of them print a warning:

[!] storing sso token from the credentials cache: Failed to update item in keychain: The specified item already exists in the keychain. (-25299) 

and occasionally:

[!] error retrieving IAM Identity Center token from secure storage: The specified item could not be found in the keyring

The commands still succeed, but the warnings clutter script output. (Same second message as #781/#844, but a different cause.)

Suggested fix: replace the lines

granted/pkg/cfaws/assumer_aws_sso.go

Lines 160 to 163 in 9339cff

	// store token to storage to avoid multiple logins
	if plainTextToken != nil {
	secureSSOTokenStorage.StoreSSOToken(ssoTokenKey, *plainTextToken)
	}

with:

if plainTextToken != nil && (cachedToken == nil || cachedToken.AccessToken != plainTextToken.AccessToken) {
    secureSSOTokenStorage.StoreSSOToken(ssoTokenKey, *plainTextToken)
}

Expected Behavior

No warnings are printed.

Actual Behavior

Said warnings are printed.

Reproduction Steps

1. Make sure the AWS CLI has a valid SSO token for the start URL in
   ~/.aws/sso/cache (e.g. aws sso login --sso-session my-sso).

2. Run assume for several profiles at the same time:

   for p in act-01/myrole act-02/myrole ... ; do
     assume "$p" --exec true &
   done
   wait

With 19 profiles, 18 runs print the -25299 warning. Running them one at a time prints nothing.

Granted Logs

No response

Granted Version

Granted v0.39.0 (Homebrew)

OS Version Information

macOS (Darwin 27.0.0, arm64)

Minimal Granted & AWS Config Configuration

[sso-session my-sso]
sso_start_url = https://<redacted>.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[profile act-01/myrole]
sso_session = my-sso
sso_account_id = 012345689
sso_role_name = myrole
region = eu-west-1

# ... more profiles like this, same sso_session

Additional Relevant Configuration

~/.granted/config:

[Keyring]
  Backend = "keychain"

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Granted repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[MohammadThabetHassan]

I traced the first warning and your reading looks right. On every assume, SSOLogin writes the AWS CLI's plaintext token into the keychain unconditionally (assumer_aws_sso.go L160-L163), even when the stored copy is identical. In 99designs/keyring v1.2.2, the keychain backend's Set first calls AddItem, and on ErrorDuplicateItem falls back to updateItem, which runs QueryItem and then UpdateItem. The Failed to update item in keychain prefix in your warning comes from that last step, so with 19 processes doing add-then-update on the same item at once, all but one hit -25299. The second message is printed by GetValidSSOToken when the keychain read fails, which fits a read landing while another process is rewriting the item.

Your change skips the write when the stored token already matches, which removes the contention in the steady state. One gap: right after a fresh aws sso login, the keychain still holds the old token, so every parallel run sees a mismatch and writes at the same moment, and that first batch would warn again. With the fix in place, one serial run before the fan-out syncs the keychain, and the parallel runs then all skip the write:

assume act-01/myrole --exec true   # syncs the keychain copy once
for p in act-02/myrole act-03/myrole; do
  assume "$p" --exec true &
done
wait

On v0.39.0 as released, the warning is harmless: StoreSSOToken only logs the error, and the run still uses the keychain copy it read earlier or the token from ~/.aws/sso/cache. If you want clean output until a fix ships, filtering just that line keeps any other error visible:

assume "$p" --exec true 2> >(grep -v 'storing sso token from the credentials cache' >&2) &