Tags disappear on managed tag provider restart >= 8.0.14

Module Development
1

The tags for my managed tag provider module “disappear” on module restart on Ignition 8.0.14 and up. (I’ve tested with 8.0.12 and 8.0.13, and it doesn’t happen with those versions. I’ve also confirmed it does happen for versions 8.0.14, 8.0.15, 8.0.16, 8.0.17, and 8.1.0).

Here is how to reproduce it:

  • Install the managed tag provider module
  • Have the managed tag provider create tags when instructed (with ManagedTagProvider.configureTag(String, DataType))
  • Observe the new tags in the tag browser
  • Restart the module
  • Observe the tags have disappeared from the tag browser :frowning_face:

This is problematic, since we have hundreds of tags created with our tag provider, and every time the module restarts, they all disappear. Any folder structure remains – it is only the tags that go missing.

There are many different times that our managed tag provider module might be restarted, and any of these occurrences result in the loss of all of its tags. Restarts of the module happen when:

  • the gateway is restarted
  • the configuration of the module is updated
  • a new version of the module is installed
  • the same version of the module is reinstalled
  • the gateway is upgraded (this is when we noticed it)

The most frustrating aspect is that we are unable to make any configuration changes without losing all of our tags, since our module restarts when new configurations are applied.

One strange thing I’ve noticed is that on the problematic Ignition versions, information about the tags created by the tag provider isn’t stored in the internal TAGCONFIG table, unlike in earlier versions. Information for newly-created folders is stored there, but information for the tags inside those folders is not. Perhaps since tag information is not being persisted in TAGCONFIG, any restart of the module loses all tag information.

I even tried to wire the tag into the TAGCONFIG table myself after it was created, based on the tag configuration when right-clicking on the tag and choosing “Copy JSON”. This only resulted in this error from Ignition as it tried to create the tags for my tag provider:

Cannot configure tag '1ab6a6b2-2a2c-44de-b8ac-1b3e47e25156', no type id specified.

So, it seems there is additional metadata stored somewhere for the tags, including type information, but I couldn’t find where that was stored in order to investigate further.

Any clues on how I might remedy this behavior? This “tag disappearance” problem has rendered our module almost unusable on versions of Ignition >= 8.0.14, which is problematic since we have upgraded to Ignition 8.0.16 (where we noticed the problem, but too late) and are looking to move to Ignition 8.1.0 LTS soon.

2

I think you should get clear on what constitutes a module restart vs perhaps a restart of your provider. When the gateway starts, restarts, your module is re-installed/upgraded, or when the user explicitly restarts the module in the Modules section of the gateway - those are restarts. I’m not sure what kind of configuration your module has and if you’re somehow making the provider restart in when it changes, but it shouldn’t be leading to a module restart.

I’m not seeing this happen with the ManagedTagProvider example from our GitHub examples repo.

Have you tried to figure out what your module may be doing differently?

1 Like
3

I’m not sure what kind of configuration your module has and if you’re somehow making the provider restart in when it changes, but it shouldn’t be leading to a module restart.

That's correct -- the module is not restarted when the configuration is changed, it only is "reinitialized".

Here's what happens in the two types of cases that exhibit the "disappearing tags" problem:

  • On a gateway restart or module install -- the module is started from scratch by:
    • Reading its configuration
    • Registering a configuration update listener
    • Creating the managed tag provider
    • Creating a control tag within the managed tag provider
    • Registering a write handler for the managed tag provider
    • Registering a redundancy state listener
  • On configuration change -- the module is not restarted but rather it is reinitialized by:
    • Shutting down the tag provider
    • Unregistering the redundancy state listener
    • Performing the startup steps again from On a gateway restart or module install above

It is strange that in either of the above cases, the tags disappear only on Ignition versions >= 8.0.14. I was hoping there might be some obvious reason why, due to a known behavior change starting with that version, but perhaps more investigation is needed.

I've looked at the managed tag provider example, but nothing jumped out at me as to why it would not exhibit the same behavior. I'll build and install that module, and try the following:

  • See that the initial 10 tags are created
  • Change Tag Count to something higher, like 20
  • Restart the module
  • Check if the 20 tags are present, or if there are only 10

It looks like the managed tag provider example always will try to make sure there are at least 10 tags on startup, but I would expect that if I create 20, that on restart of the module I still would have 20. Is that a correct assumption?

In any case, I'll play with it on different versions and see, and report back.

4

I just tried out those steps on the example managed tag provider module, and it is exhibiting the same “disappearing tag” problem. It’s an older version of the example module from a few months ago, not sure if that makes a difference.

To recap, my steps were to install the module and then:

  • See that the initial 10 tags are created
  • Change Tag Count to something higher, like 20
  • Restart the module
  • Check if the 20 tags are present, or if there are only 10

On Ignition 8.0.12: On module restart, 20 tags are present
On Ignition 8.1.0: On module restart, 10 tags are present

The behavior that is the same here is this: if the managed tag provider creates a tag that is not explicitly recreated by the module’s own code on restart, then on Ignition < 8.0.14 those tags remain on restart, and on Ignition >= 8.0.14 those tags are removed on restart.

Maybe that helps narrow things down?

5

Unless I'm misunderstanding what you're saying then versions prior to 8.0.14 were exhibiting buggy behavior that you were relying on.

Why would you expect any of your tag providers tags to remain after you've shut it down?

6

Why would you expect any of your tag providers tags to remain after you’ve shut it down?

Because that was the behavior that always was provided by Ignition for every version I've used, until version 8.0.14. Given that, why wouldn't I?

That prior behavior isn't "buggy" to me. It seems like perfectly reasonable, purposeful, and convenient behavior and it never occurred to me that it "should" work some different way. In lieu of documentation to the contrary, I have to rely on the behavior of the platform as an indicator of what the APIs do for me.

Since at least Ignition 8.0.3 (where I started work on my module), the behavior has been that Ignition records the metadata for tags and folders created by a managed tag provider, and recreates those tags and folders when the managed tag provider is restarted. Starting in version 8.0.14, the behavior has changed to record and recreate only the folders, but not the tags. Given that Ignition used to recreate the tags as well, that appears to the observer standing outside the black box (me :slight_smile: ) to be to be a regression introduced in Ignition 8.0.14. Are you sure the prior behavior was unintended?

If you're sure that the current behavior is not a bug, then it sounds like you are saying I will have to persist tag metadata myself if I am to be able to recreate tags when the managed tag provider is restarted. Is there some canonical way to do something like that with Ignition? Would I store the tag metadata using PersistenceInterface, or is there some better way that you could point me to?

7

I’ve gotta talk to someone with more ownership in this area than myself to get further answers.

To me, it seems plainly broken the way it behaved prior to 8.0.14. You can uninstall your managed tag provider module completely and you’re left with non-functional orphaned tags and you’ve essentially leaked memory.

image
image967×999 78.2 KB

But I’ll try to figure out what the intended behavior is and let you know.

8

Hey,

I think this all has a simple explanation. The intention has always been that a module was supposed to register tags (either through config, or simply setting values) on startup. If the module allowed user extensions, those would be stored, but the tag would not show up until the module registered it. It sounds like that part wasn’t working correctly previous to 8.0.14. You may not know this since you said you started working on your module in 8.0.x, but the “manage tag” concept existed in 7 as “simple tag providers”, and received a big rewrite in 8- which must have introduce the behavior you were relying on.

Anyhow, the good news (hopefully) is that part of the rewrite was to introduce better control over having tags persist and show up on startup. If you look at the ProviderConfiguration class, you’ll see the following properties: PersistTags, PersistValues, AllowTagCustomizations.

Are you setting any of those? The sdk example on github actually sets PersistTags and PersistValues to false, so I would expect that those would not show up on restart. What it’s trying to show is the previous 7 behavior: it does allow user config- so that will get stored- but it won’t be applied until the module registers the tag.

Try setting PersistTags=true and PersistValues=true on your ProviderConfiguration before you call getOrCreateManagedProvider, and see if that helps!

1 Like
9

Apologies for the late response – wanted to wrap this topic up based on what I found.

Explicitly using ProviderConfiguration.setPersistTags(true) and ProviderConfiguration.setPersistValues(true) caused the tags and their values to be saved between module restarts on Ignition >= 8.0.14. Thanks for that pointer, @Colby.Clegg!

I didn’t explicitly call those methods before because I didn’t have a need to – prior to v8.0.14, the default behavior did what I wanted and persisted tags and values. After all, there are 10 setters on the ProviderConfiguration class, and I don’t call all 10 when creating a new instance – I call only the setters where an override of the default is needed. If the default is doing what I want, then the assumption is that the default is fine and the setter doesn’t need to be called. And, unfortunately it wasn’t possible to know that the default behavior I was depending on was “buggy” and going against what was intended, as the intention isn’t documented.

Some suggestions on how to help others navigate ProviderConfiguration in the future:

  • Provide some rudimentary class documentation to point out the major capabilities of the class and why they’d be used
  • Document all of the methods (even just a sentence or two)
  • Document the default values held by an instance of the class, so it’s clear when a setter should be called to change the default if the user wants something else
  • Don’t change the default values between versions – people depend on them to be stable
  • If some of the values always should be set so that the user’s intent is explicit, then deprecate the old constructor and add those parameters to a new constructor to ensure those values always are provided by the user

I know the typical disclaimers about the SDK docs being “it is what it is” applies here, and that there probably isn’t time to enhance them, but figured it couldn’t help to provide some feedback anyway. :slight_smile: Thanks again for the responsive and detailed help here in the forum – it really is invaluable!