I was updating security on my tag providers and in the process it wiped out all the tags but not the folders they were in. It worked at one plant but failed for this reason at another even though I did the process exactly the same. Good thing I had a backup or I would have spent a long time building tags again. Wiped it out as soon as I hit the 'Save Changes' button and it spun a while and never finished the save but still showed as being saved if I went off of it and came back.
Sounds like a bug you should report.
1 Like
I recall experiencing a similar oddity that was not repeatable. In my case, a full gateway restart 'brought the tags back'.
1 Like
This worked for me also. I opened a ticket with Inductive yesterday so we'll see what they find.
I used the Task Manager to stop and start the Ignition Service. Not sure if that is what you meant Chris_Bingham.
Yes, likely same end result. Except, if I have plans to restart Ignition, I typically restart the OS (usually Linux) alongwith, and verify that everything starts back up unattended following.
Just as an update, it appears this issue is related to Canary trying to read tags basically during the tag provider restart after the save process. This is something Ignition has been discussing with Canary in the past but still no resolution. Below is their assessment:
Problem
Unable to access tags after edit saving tag provider
Assessment
went over the issue and replicated it after setting some loggers
replicated the issue a second time and took thread dumps
After going over both of these it seems clear that Canary is inserting into the ignition tag actors and making some API calls using the OKHTTP3 library that are taking some time to complete
The ignition jetty webserver that is waiting for a response back from the Canary API call
1 Like