RFC: Network faults during effect processing can lead to stale state data

[erhathaway]

I suspect that network faults during effect processing can lead to stale state data might be an issue. There needs to be some validation if this is in fact a problem.

If it is a problem, I think a few solutions exist:

• Add retry logic with some sort of back off to effect processing. Expose a hasNetworkFault attribute to indicate that the UI is out of date

or

• Add a concept of request and response filter state. (This is a large change and dangerous b/c test coverage is very poor!)
  • The ui is driven off the response state
  • Effect requests are driven off the request state
  • Submission of the effects successfully updates filter response states

[dearsaturn]

Steps to reproduce either this or a similar issue:

1. Add a filter.
2. Set the column sort to sort by something that is not configured correctly. See that the query fails in the console, but the user is allowed to continue setting additional filters.
3. Update the filter created in step 1. See that a new query is run, but results do not change.
4. Note that the error from step 2 is continuing to occur, breaking every query.
5. Remove the problematic sort.
6. Note that functionality is restored queries start to succeed again.

[erhathaway]

@dearsaturn I think that may actually be a different bug. There is no validation on filter or sort names existing, and I think this is just putting bad data into the system which is breaking all future requests

[erhathaway]

@dearsaturn this RFC deals with a potential bug that happens if a network fault occurs mid request during a valid filter / sort