You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that the addition of feature_name as a request option (for analytics purposes) introduced a failing case when a filter had the key of feature_name.
I think enabling expectations would have caught this since it compares the actual versus expected load options. However, digging into it, I was not able to create a brainstem-js only failing case because the expectations kick in before the custom sync logic. If we were to push the expectations a bit further down the code path, we should be able to capture all the options presented to Backbone.sync and do a nut-and-bolts comparison.
The text was updated successfully, but these errors were encountered:
It seems that the addition of
feature_name
as a request option (for analytics purposes) introduced a failing case when afilter
had the key offeature_name
.I think enabling expectations would have caught this since it compares the actual versus expected load options. However, digging into it, I was not able to create a brainstem-js only failing case because the expectations kick in before the custom sync logic. If we were to push the expectations a bit further down the code path, we should be able to capture all the options presented to
Backbone.sync
and do a nut-and-bolts comparison.The text was updated successfully, but these errors were encountered: