Resending xAPI statements to an LRS

Question

We have a working xAPI setup that can send statements to an LRS. Our question - what happens if the statements fail either for some period or for some subset of users? Meaning that due to (pick your favorite) internet issues, LRS credentials issues, user data issues - we need to resend all statements for a period of time or selected statements for some users?

We were not planning to keep all statements on file indefinitely. We do have the underlying data and can reformulate the statements but will the LRS freak out if we resend a large collection of statements? We are a content provider sending statements to systems like Cornerstone, Saba, Degreed and other LMS systems on the market.

What do others do?

We haven't tried to solve this yet - looking for general "how do you solve for this" feedback.

Answer 1

Whether or not an LRS will "freak out" is largely dependent on that LRS and how it is deployed, etc.

As far as what the spec dictates, mostly you should be fine particularly if your statements have an id that is pre-populated. The LRS has two ways it can implement handling of statements that it feels it has seen before (statements that have an id that matches one it already stores),

• An LRS MUST NOT make any modifications to its state based on receiving a Statement with a statementId that it already has a Statement for. Whether it responds with 409 Conflict or 204 No Content, it MUST NOT modify the Statement or any other Object.

• If the LRS receives a Statement with an id it already has a Statement for, it SHOULD verify the received Statement matches the existing one and SHOULD return 409 Conflict if they do not match. See Statement comparison requirements.

• If the LRS receives a batch of Statements containing two or more Statements with the same id, it SHOULD* reject the batch and return 400 Bad Request.

(ref: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Communication.md#lrs-requirements-3)

Essentially it can accept the statement and just ignore it, or it can compare it to what it already has and reject it with a conflict status. Either way the LRS should be able to handle statements it recognizes.

A statement without an id is considered a new statement and will be assigned an id by the LRS and won't be considered a conflict.

The other problem that could be encountered would typically be a downstream system that doesn't understand how to properly handle the stored property as that would be different for statements newly stored because they didn't yet exist on the LRS. It would also be best to include a timestamp in the statement during creation, otherwise it will be set by the LRS when storing the statement and that timestamp is unlikely to match when the statement was actually created and would make the data seem out of order.