Just wanted to bring this to ya'lls attention, as it took me a while to figure out why I was getting this unexpected behavior.
I've found using views over tables to do filtering/etc. on SQL data can help to avoid all the warnings and potential delegation errors in PowerApps. When the "Longer Timeout/Background Refresh" experimental option is turned on, scenarios where you are using SQL views and updating directly to backing tables can become rapidly unworkable. In a situation like this:
the "ClearCollect" ends up functionally in a race condition with the refresh, most of the time failing to capture the post-change version of the data, and instead using the cached data on the table.
Seems like there could be some kind of flag on a data source that indicates if it's background refreshing, that will make any collection calls of this type wait for completion before continuing. Took me half a day to sort out what was happening here, so making this more transparent to users SOMEHOW might be nice as well, even if it's just a warning notification on the field.
I noticed that when this experimental feature is turned on, my data refresh statements don't update the gallery.
In a button's OnSelect fuction, I update data in a database, then refresh the datasource so that the gallery displaying the table data will reflect the change. With experimental feature turned on, no refresh occurs. With it turned off, refresh works as expected.
I can confirm that this is still an issue with the "Longer Timeout/Background Refresh" experimental option is turned on. In my testing Button: ClearCollect(colTest,SortByColumns('[dbo].[View_StartScreen]',"TripStartTime",Descending)); with that option on I had to click the button 2-6 times before new records would load. Turning the option off resulted in new records being loaded first try.