You are currently reviewing an older revision of this page.
Background - In the time of Nikita - we had an issue where we were updating IA synchronously after a rule rename but that was causing concurency issues. Nikita started to fix the thread saftey of the IA persistance calls in DL, but we came up with a faster workaround. The work around assumed that all objects that are listed as dependencies of an object are already using uuid references. Basically we run expression search before IA updates have completed but filter out results that are already dependents of the object in question
Current Discovery - At least for bulk load of objects into IA on site startup it appears that by name references are listed as dependencies. Therefore we would not report them as by name references to the user, but they would not be updated after the rename
So issues at play:
1) some by name references will not warn the user
2) On import we never warn the user about by name references and they do exist sometimes on objects that are already on the system
Options to address that we discussed:
1) Go back to synchronous IA updates for the warning, fix the concurrency issues, and add a warning on import
2) Avoid the problem and create a fix-up process that will periodically find by name references in K and update them - so hopefully they don't exist by the time a user performs a rename
3) We didn't talk about this one ... but maybe we could save all the other objects before the rename to force there to be no by name reference? Or load the raw expressions from K and save them if there are any references?
The dependent objects that did not update to use the renamed rule's new name and were missing from the renamed rule's dependency list, were "by name references". This means, rather than the dependent object identifying the renamed rule by the UUID, it was only identifying it by name (Ex. EPC_reactivateUser rather than a_XXXXXXXXXX). When the rule was renamed, dependent objects know to update with the new name because they look at the renamed object's UUID (so even if the name is changed, the UUID does not, and the dependent object knows it is the same rule). However, dependent objects that do not reference the renamed rule by UUID, and do these "by name references" will not update on rename, because it does not know the object it is referencing has been renamed.
Normally, when re-naming a rule, a pop-up warning appears that dependents are using "by name references" and those dependents should be updated manually. However, there are some scenarios identified where this pop-up will not show. The product team has been made aware of these scenarios and are investigating them internally.
This article applies to all versions of Appian
Last Reviewed: October 2019