Good morning. I’ve come across a situation where a Workflow’s external trigger credentials are being deleted, while they are still in use by other copies of the workflow. If the token is regenerated in the trigger step, the original token is deleted from IDN. This causes other copies of the workflow that was still using it to break.
Steps to recreate:
Create a workflow with an External Trigger step, and generate the Client ID / Secret in that step.
Create a copy of the workflow
In the new copy of the workflow, generate a new Client ID / Secret.
At this point the original client ID that was being used is deleted from IDN. The first workflow is still using it, and has now broken. It should be considered before deleting the Client ID, to check for other Workflows that are using it and do not delete it if it is still being used elsewhere.
I agree that we do not want the same token on both workflows. The default behavior however on copy uses the same token, and then you cannot generate a different token for the new workflow copy without breaking the original. Yes you can generate a new one on the original too, but it seems unnecessary. Updating external secret stores and the external triggering scripts each time is bothersome too.
Yeah, your point makes sense. Might be better, even, that when the workflow is created the token is not and has to be generated in the new workflow without affecting the original at all. Instead of duplicating, have you tried downloading the JSON and editing the token out, then uploading a new workflow?
I agree with Tony that this seems like a bug, and a good way for someone who is attempting to debug or modify a workflow by making a copy to work with to accidentally break the primary workflow.
I believe that Vincent’s last suggestion about downloading then importing the JSON could be a work around, but that still doesn’t resolve the primary issue with changing the Client ID/Client secret in a workflow copy should not affect the original.
So I tested this issue and I can recreate it. I opened a Bug topic for it to hopefully get some traction, but it would probably be best for Tony to create a Support ticket for this.
Hello, Roberto from Customer Support here, I am handling Tony’s ticket and just wanted to point out a possible workaround while we wait for engineering to fix this issue:
Once the duplicate workflow is created, immediately delete its external trigger and replace it with a new one. That way, the triggers for both workflows are unlinked and any changes to the new workflow’s trigger won’t reflect in the original workflow.
There is a workaround for this issue in my message above. Also, the bug report has already been accepted by engineering and it’s in their backlog, but no information about when it’ll be fixed and released.
Thanks Roberto, I was following up for the status of the Bug Fix. Looks like it is in the backlog. How would we be able to track the status of that box, aside from requesting it from you? Is there a UI or site we could monitor?