[IGN-16084] system.tag.importTags broken in 8.3.5?

Ignition
,
1

hello @paul-griffith,

in Ignition 8.3.5, we use system.tag.importTags with "o" policy.
to add some udt instances with a basePath.
(before we delete the basePath with system.tag.deleteTags).
the json file if retrieve with system.tag.exportTags.

Tags are created in the designer:

image
image156×319 5.02 KB

but we have the following error:

Failed to push CreateResourceOperation{resourceId=ResourceId{resourcePath=ignition/tag-definition/dirmc/_intern/cme/esc, collectionName=core}}: CREATE conflict: 'ResourceId{resourcePath=ignition/tag-definition/dirmc/_intern/cme/esc, collectionName=core}' already exists

and the ressource is not updated on disk !

image
image819×230 14.8 KB

Not sure it was ok before in 8.3.4 ?

2

Seems to be OK, with a sleep 5s after the system.tag.deleteTags !

3

Unfortunately this isn't new behavior, it is just exposed better in 8.3.5 as the logging level has been changed from TRACE to WARN. We have a ticket created to address the problem.

Due to the impact that writing files to disk has on the system, when multiple changes occur to tags we do what we can to optimize the writes. In this case the delete and the create are coming in within 100ms (the debounce we have set) and everything is getting flattened to only include the create. The create is then attempting to overwrite the files that were never deleted and the signatures are now out of sync. They will remain out of sync until the Gateway or Tag Provider are restarted which makes this even more problematic.

As you noted, a sleep statement between the delete and the import will help, but there is a caveat to it. If the resource system is in the process of persisting tag definitions to disk via larger imports already, any new requests are queued up and consolidated until that process finishes. Depending on the OS, the number of folders/files, and drive speed; requests can take much longer than you might expect to be persisted to disk (10K files can easily take 90s even on a quick drive). We have new metrics in 8.3.5 that can be used to determine the time it takes or note that anything is pending and the time things take that can help you estimate or potentially code around this specific issue until we get it fixed:

From the Gateway UI, the Diagnostics. Metrics Dashboard now has:

  • configuration.push-queue: Pending writes to disk
  • tags.provider.<provider name>.storage.batch.configPushTime: How long it is taking to persist tag configurations to disk
  • configuration.resources.ignition.tag-definition: Information specifically about tag definition resource CRUD operations
  • configuration.resources.ignition.tag-type-definition: Information specifically about tag type definition (UDT Definitions) resource CRUD operations