Creating new action and trigger for that action can fail in the same import

[jmac105]

Description

When an import should create an action and create a trigger for that action in the same import, it may fail.

Reproduction

Create a new action and set deploy to true for that action. Also create a trigger on the relevant flow that uses this action

The issue is intermittent, I've seen it cause an error 1 time out of 3.

2021-10-06T13:48:23.323Z - info: Created [actions]: {"id":"686b8073-f2d1-45d7-9014-a694ddd02104","name":"force email verification"}
2021-10-06T13:48:23.494Z - info: Updated [actions]: {"id":"f0094a27-2709-4d35-847e-a5345b05668e","name":"redirect user"}
2021-10-06T13:48:25.606Z - info: Updated [actions]: {"id":"2cc1de47-d9de-4fff-9b3a-bb4976f1f07d","name":"add info to tokens"}
2021-10-06T13:48:25.741Z - info: Deployed [actions]: {"id":"2cc1de47-d9de-4fff-9b3a-bb4976f1f07d","name":"add info to tokens"}
2021-10-06T13:48:25.772Z - info: Deployed [actions]: {"id":"f0094a27-2709-4d35-847e-a5345b05668e","name":"redirect user"}
2021-10-06T13:48:25.783Z - info: Deployed [actions]: {"id":"686b8073-f2d1-45d7-9014-a694ddd02104","name":"force email verification"}
2021-10-06T13:48:25.919Z - error: Problem running command import during stage processChanges when processing type triggers
2021-10-06T13:48:25.919Z - error: Trying to create a binding for an action that has not been deployed yet.

where the triggers file included all 3 of the actions referenced above. As you can see, the 'force email verification' action was only created during this import. Running the import again worked as expected.

Environment

Please provide the following:

• Version of this library used: 7.3.1
• Version of the platform or framework used, if applicable: Node 16
• Other relevant versions (language, server software, OS, browser): command run a0deploy export -c config.my-tenant.json -f directory -o configuration/

[geoffatsource]

Same thing happened to me the first time deploying a new action

[geoffatsource]

The only way I've found around this is to manually create an action in the dashboard, do a dump to a temp directory, then cherry-pick the changes into tenant.yaml before import.

[geoffatsource]

I'm stuck .. getting error Problem running command import during stage processChanges when processing type actions

Is anyone maintaining this repo?

[MGough]

We're also seeing this issue. We have two actions, both running Node16. The only difference in the one which is breaking the deploy CLI tool is that it has dependencies set. It's just a couple of small packages, but it looks as if the CLI tries to bind the action to the flow before it has deployed due to a lag in downloading the dependencies?

[MGough]

I've realised this is actually linked to the fact that we have an action which we set deployed: False for specific environments/tenants.

The deploy-cli tries to set the triggers:

Problem running command import during stage processChanges when processing type triggers
Trying to create a binding for an action that has not been deployed yet.
error Command failed with exit code 1.

but fails as we don't deploy that action in that tenant. We don't care about the triggers, but due to the lack of AUTH0_EXCLUDE_ACTIONS (#397 ) we can't easily avoid this

[MGough]

I have now discovered that once something is set to deployed: True it can't be set to false again. For me this issue is definitely tied to the lack of AUTH0_EXCLUDE_ACTIONS or similar.

For now I've had to wrap my action code in:

if (event.secrets.enabled === "ENABLED") {
     <actions Code here>
}

and have set a 'secret' on the environments where the action is to be used.

[willvedd]

@MGough thanks for the thorough analysis. Looking at this further, it appears that the Trying to create a binding for an action that has not been deployed yet is an error returned from the API, not the deploy CLI. You're correct that it appears to occur because you're binding a trigger to an action that you don't intend to actually use in a specific environment.

As for the fix, the deploy CLI will need more intelligently orchestrate the binding of triggers to skip actions that aren't enabled (if I understand correctly). I'm not sure what unintended consequences might spur from that though. We'll just need to review this bug more thoroughly to see.

Until a fix can be rolled out, your workaround appears to be functionally sufficient. Having a production-only action enabled for all environments is certainly not ideal and neither is having an enabled "secret" but it looks to get the job done.

I have now discovered that once something is set to deployed: True it can't be set to false again.

This seems to be a separate issue, no? I'm not even sure if you can undeploy an action, that's something we'll also need to investigate. Nonetheless, I'd like to treat the original issue and this separate so I invite you to create a separate issue to discuss further.

[MGough]

This seems to be a separate issue, no? I'm not even sure if you can undeploy an action, that's something we'll also need to investigate. Nonetheless, I'd like to treat the original issue and this separate so I invite you to create a separate issue to discuss further.

Thanks for the quick response. I think that flag is a bit of a red herring, but it's probably due to the underlying API which makes it seem configurable. As the triggers are essentially a second-class citizen within the action object it looks like it will control whether or not the action is running, when in reality it's not a particularly meaningful/useful field to the end-user.

For a tiny bit of additional context we also tried setting supported triggers to an empty list [] but that didn't pass validation.

Happy to cease my side-tracking here. I realised after my initial post that the problem seemed to be different and would be resolved by an issue I'd raised a while back (#397), but once I'd found a workaround that might be relevant it seemed worthwhile posting in case anyone else was stuck. I'll disappear back to my own thread now 🙂 .

[willvedd]

Thanks for everyone's patience here. We've finally offered a fix for this in 7.17.7.

This issue was occurring because though the backend is eventually consistent with respect to actions, newly-deployed actions aren't immediately available for trigger binding, there is a short delay. This means that a race condition would occur and it would be possible for the Deploy CLI to attempt binding before they "register". The solve here is a short delay to smooth-over these types of instances; it is a naive but effective solution in our testing.

Again, I thank everyone for chiming-in here. I'm going to close but if there are further issues, please comment and we can look into re-opening.

[vinh-point-me]

running into the same issue still; errors: error: Problem running command import during stage processChanges when processing type triggers 2023-08-01T23:01:14.118Z - error: Trying to create a binding for an action that has not been deployed yet.