Push the mutation query into queue when network error occurs but client is not offline?

I expected the mutation to be pushed into the offline queue if the device is not offline and a network error occurs. But it just doesn’t happen and I can’t also find the method to watchOfflineChanges.

const mutationOptions = {
    mutation: ADD_TASKS,
    variables: {
        label: "wtf"
    },
    updateQuery: {
        query: ADD_TASKS,
        variables: {
            label: "wtf"
        }
    },
    returnType: "Task",
    operationType: CacheOperation.ADD,
    idField: "id"
};

const client = new OfflineClient(offixConfig);
client.init().then(_ => {
    client
        .offlineMutation(mutationOptions)
        .then(data => console.log("data", data))
        .catch(error => {
            if (error.networkError /*&& error.networkError.offline*/) {
                const offlineError =  error.networkError;
                offlineError.watchOfflineChange().then(console.log("offline_data", data));
            } else {
                console.log("err", error);
            }
            return error;
        });
});

I added the offlineQueueListener here:

export const offixConfig = {
	httpUrl: "http://192.168.43.39:4000",
	wsUrl: "ws://192.168.43.39:4000",
	offlineQueueListener: data => {
		console.log("queue", data);
	}
};

Or may be, am I doing something wrong?

[darahayes]

Hey folks, just wanted to jump in here. I don’t think I’ll be very helpful in providing you a solution that you can use right now but I did want to just provide some info on the work I’m doing that may help you in the future.

I expected the mutation to be pushed into the offline queue if the device is not offline and a network error occurs.

This is an area we’ve struggled with. In an ideal world we would do this automatically but the challenge is ‘How do we define what is and isn’t a network error?’ As @wtrocki mentioned before, we’ve tried this in the past and encountered issues. One of the things we want to avoid is having an item in the Offline Queue that simply cannot be fulfilled. If this happens we need extra logic to catch that case, or the queue seizes up and your application gets into a pretty bad state.

The other thing is that different users will have their own opinions and definitions for the various error states that their application will deal with. One example of how we deal with that is the NetworkStatus interface, but it seems we still have issues around making it easier to decide how/when something should be enqueued.

There have been some suggestions above for extra flags such as isOffline and saveToOffline but I feel like these flags don’t make a lot of sense, and they would only enable really specific use cases. It would be an ok solution until someone else comes along and wants another flag for their particular use case. Next thing we know, the API is bloated with flags that are impossible to understand.

In my opinion, the bigger problem here is that the Offline Queue is too much of a black box. Ultimately I think the queue needs to be accessible so users can decide themselves how/what/when to enqueue operations, and to have some control over when they will be fulfilled.

Right now I’m working on #170 which will give you direct access to the queue on client.queue.

Just some examples of things you’ll be able to do on the queue itself:

• queue.enqueueOperation - add a mutation to the queue (and persist it)
• queue.dequeueOperation - remove a mutation from the queue (and remove from storage)
• queue.forwardOperations - fulfil all operations in the queue.

I see client.offlineMutate as being a high level API that can cover the most common situations and if you need to do some more advanced things, then the lower level queue API will be available directly.

Any feedback on those ideas would be massively helpful!

[garsharm]

Okay, @wtrocki. Thanks for the quick reply. and a few things I want to clarify regarding the implementation.

1. as of now context: {...context, isOffline: true } is pushing the mutation in the offlineQueueListener: { onOperationEnqueued: (entry) => { console.log(entry) } } but not queuing in offline store array. right? I think because we are pending with Issue #147.
2. Also, the functionality to trigger these queued mutations is not implemented yet. right?