Error "rules is cyclic or exceeds maximum cascading level"

FlorianArtelt

We are using an atrribute rules in ArcGIS Pro 3.1.4.. We want to update a number of features in the feature layer on which the rule is located. We am trying to create an attribute rule that updates the "Pushvalue"-field across all features in the same layer that share the same "GemeindeID".

We have seen the following solution approach, that describes how we prevent running into an infinite loop.
We do not see how we can escape the infinite loop in this example.

Solved: The Evaluation of attribute rule is cyclic or exce... - Esri Community

But we are still getting the cascade error message: "rules is cyclic or exceeds maximum cascading level". And we think that this is justified since the changes in the individual lines triggers the attribute rule over and over again. @IlkaPleiser1 @JohannesLindner  @HusseinNasser2 

 

// calculed Field $feature.Helper
// Triggers: Insert, Update
// Exclude from application evaluation


var GID = $feature.GemeindeID
var GLID = $feature.GlobalID


// filter current featureset except the feature that is edited rn
var SQL = "GemeindeID = @GID AND GlobalID <> @GLID"
var sirenen = FeatureSetByName($datastore, "Sirenen", ["*"])
var filterSirene = filter($featureset, SQL)
console(count(filterSirene))

var updates = []
for(var f in filterSirene) {
    if(f.GlobalID == $feature.GlobalID) { continue }
    var u  = {
        globalID: f.GlobalID,
        attributes: {
            Pushvalue: $feature.Pushvalue
            }
        }
    Push(updates, u)
}

return {
    result: {
        attributes: {
            Pushvalue: $feature.Pushvalue}
        },
    edit: [{
        className: "Sirenen",
        updates: updates
        }]
}

 

 

 

HusseinNasser2

This one is really interesting, just found another issue when you have more than 6 features to update, because we have a limit of the number of Arcade engines the script hit that limit pretty soon.  

 

The only workaround to really fix this is to have an additional field, I added a field called isPush with a integer value. We want to essentially differentiate between a user update changing the pushvalue vs an automated attribute rule update. 

You can hide the ispush field from users as it will only be used by the attribute rule.

 

if ($feature.ispush == 1) return {"result": {"attributes": {"ispush": 0}}};

 

Final script.. 

 

// calculed Field $feature.Helper
// Triggers: Insert, Update
// Exclude from application evaluation

//add base condition 
if ($feature.ispush == 1) return {"result": {"attributes": {"ispush": 0}}};

if($originalFeature.pushvalue == $feature.pushvalue) return;

var GID = $feature.GemeindeID
var GLID = $feature.GlobalID


// filter current featureset except the feature that is edited rn
var SQL = "GemeindeID = @GID AND GlobalID <> @GLID"
var sirenen = FeatureSetByName($datastore, "Sirenen", ["*"])
var filterSirene = filter($featureset, SQL)
console(count(filterSirene))

var updates = []
for(var f in filterSirene) {
    if(f.GlobalID == $feature.GlobalID) continue;
    //don't update values that are the same to avoid recursion.
    if(f.pushvalue == $feature.pushvalue) continue;
    var u  = {
        globalID: f.GlobalID,
        attributes: {
            Pushvalue: $feature.Pushvalue,
            ispush :1
            }
        }
    Push(updates, u)
}

return {
    result: {
        attributes: {
            Pushvalue: $feature.Pushvalue}
        },
    edit: [{
        className: "Sirenen",
        updates: updates
        }]
}