A colleague of mine has observed the same thing, but thought it was something wrong with his installation. It's very interesting to hear about others experiencing the same issue. My suggestion is that you record a short video and send it to Safe support, I'll ask that my colleague do the same.

So it happened to me yet again. I still don't know what exactly triggers this behaviour, and I was too busy in fast correcting the problem to make a video.

But since it's a well recognized behaviour, i.e. reverting a workspace back to its default setting when editing/saving an automation, someone from Safe might be able to make a qualified guess as to what could potentially trigger such a reset ?

Hi @Lars I Nielsen​ ,

This does sound buggy. A couple of questions to dig deeper...

• Are you experiencing this behavior for 1 specific automation or multiple?
• Is the behavior with specific Triggers?
• Have you experienced this in previous versions or only in 2022.2.2?

I agree with David, if you can screen record this the next time you experience this and submit a case here, that would be great.

Thanks,

Kezia

Thanks Kezia.

As for doing a recording, I just edit multiple automations, and later occasionally find some of them having been reset. So I can't see how I can do a recording of me editing an automation, saving it, and surprisingly find that it has been reset. I may even have to save/close and reopen it for it to happen, I don't know.

And yes, it has happened to me twice in two different automations, so it's not a single problematic automation at fault.

I may in my editing have: deleted an "automaton" (what's the name of an item in an automation??), redone some connections, changed some automaton parameters, changed some global parameters, or even attempted to add a manual trigger.

I cannot say for sure what triggers it. But most edits do not trigger a reset, and works just fine.

Will some log files be of use ? If so, which ?

Cheers.

@keziaatsafe​ @david_r​ 

So it happened to me again. And this time, I'm pretty sure what I changed.

I changed the value of a global parameter !

So this is my best guess as to what triggers the unwanted "cleaning" of the action parameters.

Hi @Lars I Nielsen​ ,

Thank you for the update. I did a quick test in FME 2022.2.2 b22765 and 2023.0.0.3 b23319 and unfortunately could not reproduce the issue when changing the value of a global parameter. Are you able to share a sample automation and workspace for us to test with? What specific build of 2022.2.2 are you using? I'd like to file a ticket once we can get a repro of the issue.

Thanks,

Kezia

Hi Kezia.

Alas, I had to do the same procedure (duplicating and editing an automation), and was very observant as to whether it "reset" or not. Fortunately, or rather unfortunately for this issue, nothing amiss happened, so even I can't reproduce the error, it seems.

I'll revisit the automations tomorrow, tinker a little about, and see if they suddenly fail.

The editing I had to do previously, was caused by failed runs due to missing edits, so I don't hope that I'll need to run them again with errors before something happens.

Hi @keziaatsafe​ , my colleague was able to find a way to reproduce the issue fairly repeatedly and has shared his detailed findings, including screenshots and video, in support ticket C691945. I hope this helps you find a solution. Feel free to reach out to my colleague or myself if you need further assistance.

Hi @david_r​ and @Lars I Nielsen​ ,

Thanks to Alex's recording, and this community thread, I was able to reproduce the issue in 2023.0 and have filed a ticket for our team to look into this. For internal reference eFMEFLOW-21070]. In my testing, it was a little hard to reproduce again on the same automation, so I made a note that this behavior may only occur on the first edit of global automation parameters. This may explain why @Lars I Nielsen​ couldn't reproduce again afterward. I'll update the thread when I have more information to share.

Thanks,

Kezia

Hi @Lars I Nielsen​ ,

Hope you're doing well. Just a quick update on the bug. The development team is currently working on the issue and has a couple of follow-up asks.

• In your experience, were you seeing the behavior with a specific parameter type in particular? I was able to repro it with a file-type parameter and David's colleagues' recording was with the text-parameter. Was this occurring with all parameter types or are any other that you noted? Can you confirm which parameters you have observed this with?
• Would you be able to share any workspaces for the development team to work with? If so, please submit a case with the attachment and I can pick it up.

Thank you in advance!

Kezia

Hi Kezia.

I have only been using textual parameter types.

I don't think it has to do with the workspaces, since they're unaffacted. It's only their starting parameters inside the automation that fails to be persistent.

So any workspace will probably do for testing.

I have been using global parameters for some of the parameters, to ease multiple deployments of the same (duplicated) automation.

Cheers.

Hi @Lars I Nielsen​ ,

Thank you for the update! The fix for this issue is available in 2023.1 build 23611 and newer.

Kind Regards,

Kezia