Using the action twice in a job with short session duration makes the configuration fails.

[azarudeena]

Describe the bug

we have use case where we runner our smoke tests on the self hosted runners on a internal application which restricted with in our network. we use this action in github workflow to allow list the runner public IP and remove it after the tests the aws cli with the configured session in using GitHub OIDC session with the below sample code.

     name: Smoke Test Execution
    runs-on: [ self-hosted, linux, x64, ubuntu, public ]
    steps:
      - uses: actions/checkout@v3
      - name: Configure `staging` AWS Credentials
        uses: aws-actions/configure-aws-credentials@v3
        with:
          role-to-assume: ${{ secrets.AWS_IAM_ROLE}}
          aws-region: ap-southeast-1
          role-duration-seconds: 900
          role-skip-session-tagging: true

.... allow list node 

.... execute tests 

      - name: Configure `staging` AWS Credentials
        uses: aws-actions/configure-aws-credentials@v3
        if: always()
        with:
          role-to-assume: ${{ secrets.AWS_IAM_ROLE }}
          aws-region: ap-southeast-1
          role-duration-seconds: 900
          role-skip-session-tagging: true


.... remove the allow list 

after upgrading to v3, the second time session configuration before removing the allow is failing with the below error screenshot saying the token is expired which was never the case when using the v2. currently we have all the workflows running in v3 except this one scenario. My guess is that env are getting the precedence from the previous configuration session which was short duration.

Expected Behavior

The same setup with v2

Current Behavior

Please refer the screen shot from bug description.

Reproduction Steps

for us the some tests take like 10 to 15 mins. May shorten the duration of the session and use a sleep in a github actions step for that duration and trying configure session with v3 version.

Possible Solution

check for the session being expired when existing configs present, if yes retry to configure. either it will override the config or error out with some other error not the expired one.

Additional Information/Context

No response

[peterwoodworth]

Just to be clear, you're using OIDC to assume the same role both times?

[peterwoodworth]

Ack, I know what did this. Thanks for reporting

[peterwoodworth]

For now you should be able to use unset-current-credentials: true to work around this

[azarudeena]

@peterwoodworth Thanks for the quick turn around.

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.