Automation Parameters are Resetting

Yes, I have seen this happen as well. And I spent a lot of time trying to replicate it without being able to pinpoint the cause, although I could see that the front end did not make the api call to update the parameters. My case was "C684074 - Automation returning to default value" but without the ability to find the reason, it was hard to fix.

There was a bug in FME 2019 where Choice (Multiple) parameters which had a space in them would not save in an Automation (the save button reset the parameters). It had to do with space being used as a delimiter for the multi-choice parameter, and funky use of "quotes" "around parameter" "names" in the automation. If you create a plain workspace with a simple text parameter, does it still get reset to defaults?

I can actually reproduce my error pretty easily. It happens whenever I overwrite an existing workspace from Forms that is in an existing automation. I even changed to deployment parameters where I could and eventually had to set up defaults per parameter so it would not break if I made future changes.

I think the issue was with the space in the parameter dropdown list. We have a Dev, Test and Prod environment, to make sure we see if we are in production we made the name GIS Gateway. I removed that option from all workspaces in 1 automation and am no longer able to reproduce the issue.

I have 3 more automations and probably 10 more workspace to go through. This should prove it this was the issue!

Thanks again everyone!

Still have this issue on certain workspaces / automations in FME 2023.1. 23619. It seems to be related to when the automation changes somehow. Difficult to debug, but the end result is that at next time the automation runs it has the default values and not the correct values.

It has happened several times on several workspaces the last months now, so we are trying to figure out what the issue is.

Any more update on this from Safe Software side?

I had noticed this previously, but not for awhile until yesterday when I updated an automation “global.” parameter and all of the workspace parameters were reset to default so the automation no longer worked.  Nothing else changed - none of the workspaces were republished.  All I did was stop the automation, change the automation parameter and restart the automation.

FME Flow Hosted Build 24620.

I appear to have run into this issue today - Build 24612

Appeared again for us also. FME 2023.1. 23619.

We have experienced this with FME Flow 2024.2.3 Build 24825 - win64 just this week.  Prior version was FME Flow 2024.0 Build 24187 and we had it happen there also.

We have experienced this with 2024.2.1 Build 24801 - win64. It was triggered by changing a value of an Automation Parameter in the Editor. Has a workaround been found yet?

An update, with help of my colleagues:

• There doesn't seem to be a one-size-fits-all solution (yet)
• We think it might have something to do with the application database that does not respond fast enough. More RAM might minimize the problem.
• It seems as if installations with an external database experience less problems with this.
• I’ve heard more recent FME Flow versions have less problems, but rumours that it has also happened on FME Flow Hosted?

The following workaround can be used for now:

• Make a ~daily (or a timing that suits your edits) back-up (automated, of course) of the specific Automation, and put it back when the Automation Parameters were reset again. That way, you don't have to manually type the automation parameter values again.
• Some use ‘Projects’ in FME Flow to store the back-up of the automation (.fs file).

I hope this might help a bit.

Plenty of RAM on our server (96 GB), and also the available RAM is more than 50 GB usually. So that might be rule out I would say. Database is “internal express install” so not external db.

Hello, 

Same issue with FME Flow 2024.1.3 Build 24627 - win64

Do you know when a fix will be available ? 

Hi everyone, I received some more information via my colleague, who submitted a question to Safe Software. The main takeaways are:

• There is a fix for an issue where deployment parameters were causing the Automation parameters to reset in the 2025.0 release.
• If this isn't limited to deployment parameters, they hope implementing the V4 REST API with the 2025.1 release fixes the issues with resetting automation parameters. So they recommend waiting to upgrade to 2025.1 (planned for early July) when it does come out. 

Experienced this issue with FME 2025.1, Build 25606 - linux-x64. It was also triggered by changing the value of an automation parameter in the editor. 

It’s really fun when it’s a password parameter that you can’t even see has changed!

I’ve also been having some weird issues (2024.2.2 Flow Hosted and also 2024.2.2 Express Windows) - It’s hard to say if the issue is me or the Automation. Either way it’s been a bit frustrating. 

I’ve even seen the issue where a Project containing the automation either wasn't exported or imported properly - hard to say. The result was missing several parameters. But this could have happed as a result of editing the parameters after import. 

Could very well be related to editing the Automation/Global parameters.  

OK I’m pretty sure the issue is somewhere in one of the js files which is run combined with some state stuff. 

I found that if I have parameters of certain types (e.g., number) inside of a group parameter then these are much more likely to get dropped.

I’ve also seen that if I click the padlock button to lock the parameters then the number type parameter disappears and (a clue) is that the value changes from “_text_uniline” to the actual key e..g,  {route.NewFeautreType._text_uniline}

 

The same thing does not happen if I’ve just edited/set the parameter values - clicking the lock after just editing and saving is fine.

I’ve made copies of the workspace where I have removed the group parameter and I am not seeing the issue at all. 





 

Great detective-work ​@virtualcitymatt - hope Safe Software looks into it backend

The workspaces I have seen the same issues with do not have any group parameters

Yeah - indeed this does also happen, seemingly randomly, when they are not inside Group Parameters, however, I’ve found that it can 100% be reproduced in this way. Indeed given the reported randomness of this problem/behaviour I can only assume there is more than one issue. 

As soon as I removed the group parameters though, it’s been stable, however, I’ve very much tried NOT to edit it too much.