DTP-711: Handle SequenceId edge cases

[kaschula]

This PR adds tests and validation handling for the sequenceId return from the configured sync function.

Conditions:

• 1. SequenceId is undefined
• 2. SequenceId is '0' and there is history in the channel. In which case history should be applied.

Previous PR: #162, I had to change the branch name because I used the wrong jira reference. Old comments are here are on the original PR

Comments

In condition 1 where the sequenceId is undefined, the solution in this PR is throw an error and set the model state to errored. Additionally the retryable() logic has been updated to not run the callback function if the model is in the errored state. Additionally if we catch an error while in the errored state then we re throw it, propagating it up the call stack. This is how the new sequenceId is undefined error will be surfaced to the user.

Other changes

Error handling has been improved so that all errors produced by the SDK during event handling function or in places where a user would not be able to catch them have been silenced and are exposed through the 'errored' event.

The docs around the Models's sync and subscribe methods have been updated so that the user knows to catch any errors thrown by these functions.

An integration test has been added that covers all message history being applied to model with sequenceId 0 and, seek and applying history with a sequenceId of 1 or more.

The uuid package has been added as a dev dependancy.

The current integration test located in ./src/Model.integration.test.ts has been wrapped in its own describe as the test set up new test is different. This test are now isolated. I have also added uuids to the channel name so that each test run uses a different channel.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
models	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 21, 2024 9:46am

[mschristensen]

We should catch any error thrown by the handleErrorResume(), and log it, since we do not have a way of surfacing the error/promise to the caller to handle like we do when an initial sync throws from a subscribe call.

We should add a comment to clarify that the inner retry will stop due to the errored state being set on the model. It would be good to add a unit test for this behaviour to assert that we do not get into a retry loop when there is a stream discontinuity and the resync throws.

We should also update docs to state when the sync or subscribe promise rejects. You can then run npm run docs to update the static generated typedocs.

[mschristensen]

Looks good, minor comments then happy to merge :)

[mschristensen]

I think this should be error level

[mschristensen]

Let's merge #164 into this and then happy to approve :)