Post action step does not revert to previous role if multiple are assumed in the same job

[rr-tom-noble]

Describe the bug

We're using a custom action to deploy a stack, then tear it down in the Post action step at the end of the job. Our steps look like:

1. Assume Deployment Role
2. Deploy Stack
3. Assume Test Role
4. Run Tests
5. Post Assume Test Role
6. Post Deploy Stack (i.e. Destroy Stack)
   ...

The issue occurs between steps 5 and 6. Step 5 appears to clear the credentials with no knowledge of the previously assumed role in step 1. This results in Step 6 failing.

Expected Behavior

Step 5 should revert Step 3, but NOT revert the effects of Step 1, since the Post step for Step 1 has not run yet.

Current Behavior

Step 5 reverts Step 3, but appears to do so by wiping all credentials. This means that teardown for steps after Step 1 cannot rely on rely on the credentials for Step 1 being available, despite its teardown having not yet run.

Reproduction Steps

Can provide a more detailed example if required:

1. Create an action with a "post" step that uses AWS
2. Create a pipeline with the following setup:
   1. Calls this action with Role 1
   2. Calls custom action with Role 1 credentials
   3. Calls this action with Role 2
3. Run the pipeline. The Post step for ii will fail due to the Post step for iii clearing all credentials

Possible Solution

No response

Additional Information/Context

No response

[rr-tom-noble]

In truth, I'm not sure what the intended semantics of tear-down of steps is meant to be when the same step is called more than once. i.e.

• Tear down only this instance of the step and preserve any state of previous calls until their tear-down OR
• Tear down any state which may include the state of previous calls, making no guarantees about preserving ordering

The former feels nicer for producing reliable behaviour during tear-down, however, maybe having steps need to maintain information about whether they've been called previously is a bad practice.

I realise my use-case is somewhat niche (it only affects actions that rely on credentials during teardown). I think I can work around this by explicitly re-assuming the deployment role and destroying the stack in additional steps (pre-teardown).

Still, it'd be nice to determine whether it'd be possible to do this, and whether it seems like a good idea to do so.