Bug: Tag Leakage between Ignition Canary Collectors

In Ignition, whether you delete a single tag with its historical storage provider explicitly assigned, or a UDT instance with its tags' historical storage providers assigned through a parameter binding, the deleted tags are added to the active Canary Store and Forward stream. I suspect that this has happened in previous versions of the Canary Historian Module and the Canary platform, but I'm currently observing it using version 25.3.1.25216 of the Canary platform and version 25.0.1 (b250801300) of the Canary Historian module.

It's one thing to have to manually obsolete tags that already exist in a DataSet, but it's incorrect for the module to translate deleting tags in Ignition into adding previously nonexistent tags to just any DataSet, which I then have to manually obsolete. When there are multiple active Store and Forward streams, meaning multiple DataSets where tags can appear, this floods Ignition's historical tag browser with phantom tags.

Conditions under which this bug was observed:

• There are 4 canary collectors configured in an Ignition (v.8.1.49) gateway, which point to 4 separate Canary DataSets, per the module installation guide.
• 3 of the 4 collectors are configured with the "Collector Enabled" field set to false, and 1 of the 4 collectors is configured with the "Collector Enabled" field set to true.
• The 3 disabled collectors are configured with 1 local Canary Historian's IP address and 2 remote canary historians' host names, comma-separated per the module installation guide, in the "Historian" field.
• The 1 enabled collector's "Historian" field contains just the 1 local Canary Historian's IP address.
• There is only 1 real-time Ignition tag provider, which contains multiple folders and primarily UDT instances. Most UDT instances have tags configured to store to the disabled Canary Collectors.
• There is 1 UDT instance containing only 1 OPC tag which uses the 1 enabled collector as its historical storage provider, and it is properly storing data to the corresponding Canary DataSet.
• The remaining Canary DataSets associated with the 3 disabled Canary collectors don't contain any historian database files.

Verification of a Disruptive Workaround:

1. A new tag was created in the real-time tag provider, using a disabled Canary Collector as its historical storage provider.
2. No change was observed in the open historical database file for the day.
3. The Canary Store and Forward service was stopped on the system running the Ignition gateway.
4. The tag was deleted in Ignition.
5. The Canary Store and Forward service was started again on the system running the Ignition gateway.
6. The tag did not appear in the open historical database file for the day.

Less Disruptive Workaround

1. On the real-time tags you wish to delete, remove/override the historical storage provider so that it's not using a Canary Collector.
2. Delete the tag(s).
3. The tags should not appear in the open historical database file for the day.