Add error handlers for replication push and pull

[nirvdrum]

I apologize if this is provided in some way, but I haven't figured it out yet and I've read through replication-graphql.test.ts looking for ways to handle replication push and pull errors. If there's agreement on the issue, I can try to pull together a PR.

I'm using GraphQL replication and I have a non-primary key column that should be unique in my database. In #728, adding support for local uniqueness checks was decided against due to potential conflicts during replication. Indeed, having that would only reduce the frequency with which I run into conflicts, although could make for a nicer user experience locally. In any event, sometimes I run into issues where the GraphQL push replication fails. When that happens, I have a local document already created but it does not have a persisted version in the central database.

I'd like a way to provide an error handle for the push property in the replicator setup. Having such a handler would allow me to gracefully handle the conflict. In this particular case, I can assign a new value to the column and attempt the insertion a second time. Unfortunately, the value is not something I can generate on the server. Alternatively to fixing the document, I could use that handler to delete the local document.

The RxGraphQLReplicationState class does have a way to observe errors via its error$ field, but that is invoked on both push and pull. Moreover, it only has a reference to the GraphQL error, which doesn't have enough context to recover from. Nor is there a way to trigger a new replication attempt with the updated values.

I think what I'd like to see is an onError handler in GraphQLSyncPushOptions. For symmetry it might be worth adding it to GraphQLSyncPullOptions, although the only pull errors I've encountered have been when I've messed up a query and that's not recoverable. Although, I'm not entirely sure how that error handler could retry a push since there isn't a handle to the GraphQL client. Maybe the handler could just update the local document and let the normal retry logic replicating it during its normal retry cycle. That aside, does this sound like a reasonable feature to add to RxDB?

[pubkey]

There is still the task open to reuse the replication-primitives plugin for the GraphQL replication. I do not really want to add more features into the GraphQL replication, until the code is unified.

Can we extend the error$ observable to support your use case?

[nirvdrum]

Do you have a link describing the refactoring you're talking about? I didn't see anything in the issue tracker.

I'll try extending the error$ observable. I think that'll work and shouldn't adversely affect anyone. The error type is any at the moment, so I don't think anyone should be relying on any particular structure of that object.

[pubkey]

It is noted here

I'll try extending the error$ observable. I think that'll work and shouldn't adversely affect anyone. The error type is any at the moment, so I don't think anyone should be relying on any particular structure of that object.

Sounds good to me.

[nirvdrum]

This was addressed by #3630 and released with RxDB 11.5.0.