Unable to Resolve "The evaluation of attribute rules is cyclic or exceeds maximum cascading level" Error Message

ChristopherBowering

I have a basic AR that updates the value in a child table field when the corresponding parent field is updated (Enterprise Geodatabase...GlobalID to GUID relationship). When this is the only AR enabled, everything works as it should. However, when used in conjunction with another AR set on the child table, I receive the error "The evaluation of attribute rules is cyclic or exceeds maximum cascading level" when I update the parent field value.

Note: The 2 rules I'm using in conjunction do not use any of the same fields

See the code below. Any help would be greatly appreciated! @JohannesLindner @HusseinNasser2

if ($originalfeature.PARENT FIELD == $feature.PARENT FIELD) {
    return
}

var fs = FeatureSetByRelationshipName($feature, "RELATIONSHIP CLASS");

var updates = []
for(var f in fs) {
    if(f.GlobalID == $feature.GlobalID) { continue }
    var u  = {
        globalID: f.GlobalID,
        attributes: {
            "CHILD FIELD": $feature.PARENT FIELD
            }
        }
    Push(updates, u)
}

return {
    edit: [{
        className: "CHILD TABLE NAME",
        updates: updates
        }]
}

HusseinNasser2

I think I addressed a similar issue here https://community.esri.com/t5/attribute-rules-questions/error-quot-rules-is-cyclic-or-exceeds-maximu... there is an attached geodatabase with the example code.

This is similar to what you are trying to do, still uses a foreign key (but no actual relationship class), they have a groupId in the feature, when a certain field gets updated they want all the features with same groupid to have the same value of that field. The video explains it

The trick is to avoid calling or triggering the attribute rule when we don't need to, I think your code is almost there, just need to add an additional check before globalid check

 if(f.GlobalID == $feature.GlobalID) { continue }

 if(f.childfield== $feature.parentfield) continue;

ChristopherBowering

Thanks for the quick reply @HusseinNasser2

The adjustment worked a little bit. I was able to get the parent update to push thru given the presence of existing child table records (which immediately prompted the cyclical error previously). However, as soon as I add a new child record and the 2nd rule activates (this rule carries the most current value from a child field to a parent field based on a date field in the child table), the same error is thrown.

I did read the example you posted but got lost when the resolution involved creating new fields to accommodate the situation, which I would rather not do.

HusseinNasser2

Unfortunately in complex recursive case like this where the child updates the parent and the parent updates the child we need more context in the attribute rule itself. Currently it is not possible to differentiate between an edit made as a side effect of attribute rule vs an edit that is made directly by the user. Adding that field allows us hint us to know is this edit done by the user or is it a result of a propagation from parent which will allow us to continue propagation vs to stop. The field can be added but hidden so users don't see it.

Without this knowledge, parent updates child, which triggers the rule to update the parent which then triggers the rule again to update the child.

ChristopherBowering

I don't quite understand how this looping occurs when the rules don't involve the same fields. Whether an edit is made by a user or rule, if the rules use totally different fields (with the exception of calling out the relationship) why would they be continuously triggering each other?

In my current example - using the code last updated with your help - my 2 rules work harmoniously within the constraint of existing child records. Updates to various fields in both datasets can pass thru they way they're intended to. It isn't until a new related child record is added to the relationship that the parent-to-child rule throws the error.

HusseinNasser2

That is because attribute rules are triggered on updating any field.

the target field you set on the attribute rule view is the field you want to set the value to, not the field you that you want triggering the rule.

Updating any field will trigger the rule

ChristopherBowering

The 2 rules I've been referring to are not set to fields within the attribute rule settings. I assume this is because the code takes care of everything and this isn't needed. Would specifying the field in the settings - vs leaving blank - alter how the triggering works? I apologize for my naivety with all of this! I'm trying to soak up as much as I can because I find these rules to be incredibly helpful.

ChristopherBowering

Hi @HusseinNasser2 . I am re-reviewing the previous link/example you provided. In that case, the user was working within a feature class and needed the rule to perform an update based on a common value (GemeindeID in his case) amongst features. I have a 1-to-many relationship where there are multiple table records to a single feature (no common value field; just GlobalID to GUID relationship) and I am transferring values between datasets.

I am not sure how to set up the code you used to apply that example to my situation or where to create the dummy field (or how to use it). I'm willing to try using an extra field...assuming the rest of the concept is feasible!