Immediate calculation attribute rule, querying $datastore

[danbecker]

We have a fairly complex Arcade script that executes on Enterprise Geodatabase feature class Insert via a sync from an offline area in the field maps app. 

If we query the feature class using Filter(FeatureSetByName()), the returned feat_set does not contain $feature that triggered the attribute rule. 

var calcFeatId = -99;
var sqlexpression = "feat_id = @calcFeatId"
var feat_set = Filter(FeatureSetByName($datastore,'mydb.dbo.pt_layer',['globalid'],false),sqlexpression);

return {
            'attributes':{ //values to calculate on $feature
                'feat_id': calcFeatId
            }
        };

Is this expected behavior? 

Further, what if that same attribute rule modifies attribute values of $feature. Would the above query include $feature in the filtered featureSet? 

[DavidSolari]

From my testing, replica synchronization (i.e. what offline areas use to update the feature service) appears to attribute rules as series of individual features to C/U/D. If FeatureSetByName is reading the data outside of the current transaction, it'll just see the pre-sync snapshot which will not include new features or changes to those features. If it's reading data from within the current transaction, it might see the other operations but it might not, depending on the execution order, so you should always assume it can't.

The safest option is to assume that this type of query could or could not contain the current feature; therefore, always read/modify the input feature in addition to what you get from the query, but also assume this could result in a duplicate action and guard accordingly. This will cover both standard and sync updates. If this'll bloat your scripts too much, test how the rules behave in your environment from a variety of clients, offline and online.

[danbecker]

Thanks David. Yes, Count(FeatureSetByName) returns a different number depending on replica sync, vs. inserting a feature using Pro. 

VERY confusing and not documented at all (at least from what I could find). 

This arcade script is already bloated at 500 lines. Could be trimmed down if I take some more time, but complex. I really see no other alternative to firing a script by insert trigger. Maybe a feature service webhook would be more reliable. Better yet, that webhook calls powerAutomate flow, that invokes an Azure python runbook...