When the last subscription to a GetResponse is disposed, the GetRequest unsubscribes from the DataSource observable and removes itself from the RequestQueue. Any information about pending/in-flight network requests is lost to Falcor at this point.
When using a DataSource that makes network requests that cannot be cancelled, Falcor may create multiple network requests for the same path query. Such a situation can occur when e.g. starting and cancelling Falcor get requests in a React component's lifecycle methods. This is not a bug, but a side effect of internal request cleanup.
I propose we add a flag to Falcor.Model and/or allow a readonly property on the DataSource interface to communicate to Falcor whether underlying requests can effectively be cancelled, and, if not, that GetRequests are retained on the RequestQueue even after all callbacks are removed (i.e. all subscriptions disposed).
When the last subscription to a GetResponse is disposed, the GetRequest unsubscribes from the DataSource observable and removes itself from the RequestQueue. Any information about pending/in-flight network requests is lost to Falcor at this point.
When using a DataSource that makes network requests that cannot be cancelled, Falcor may create multiple network requests for the same path query. Such a situation can occur when e.g. starting and cancelling Falcor get requests in a React component's lifecycle methods. This is not a bug, but a side effect of internal request cleanup.
I propose we add a flag to Falcor.Model and/or allow a readonly property on the DataSource interface to communicate to Falcor whether underlying requests can effectively be cancelled, and, if not, that GetRequests are retained on the RequestQueue even after all callbacks are removed (i.e. all subscriptions disposed).