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

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/

[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]

@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.