I was working on an issue where a field updated event created a stack overflow exception. The root cause appears to be explicitly updating the cache during a FieldUpdate event.
Example of bad code:
protected virtual void _(Events.FieldUpdated<MyDAC.myField> e)
{
var row = (MyDAC) e.Row;
row.SomeField = "ABC";
row = (MyDAC)e.Cache.Update(row); // <--- NOOOOO!!!!!!
}
This likely stems from a common practice of SetValueExt followed by Update, such as in Actions. However, updating the cache within the FieldUpdated event is incorrect. Although the offending code has been unchanged for about 3 years, either another customization package or an update to Acumatica base code resulted in over 100 iterations ending in a Stack Overflow exception.
This condition does not appear to be reported by Acuminator, although I have seen numerous posts discouraging the practice as incorrect within a FieldUpdated event.
I was working on an issue where a field updated event created a stack overflow exception. The root cause appears to be explicitly updating the cache during a FieldUpdate event.
Example of bad code:
This likely stems from a common practice of SetValueExt followed by Update, such as in Actions. However, updating the cache within the FieldUpdated event is incorrect. Although the offending code has been unchanged for about 3 years, either another customization package or an update to Acumatica base code resulted in over 100 iterations ending in a Stack Overflow exception.
This condition does not appear to be reported by Acuminator, although I have seen numerous posts discouraging the practice as incorrect within a FieldUpdated event.