sendStatements() not functionally equivalent to sendStatement()?

[brian-learningpool]

I noticed while testing the ADL launch method that sendStatement() and sendStatements() are not functionally equivalent. For instance, while testing with Learning Locker v1, xAPI statements sent via sendStatements() would fail.

The same statements would succeed if used in a for-each call to sendStatement().

[vbhayden]

They aren't equivalent, but it looks to only be a difference of how the statement IDs are submitted. The singular sendStatement() checks for an ID and supplies one if necessary, whereas sendStatements() doesn't make that check and sends the array as-is.

What status code is the LRS sending back?

[brian-learningpool]

Learning Locker v1 sends back a 500 status with Attempt to assign property of non-object.

I guess the question is, should they be equivalent?

[vbhayden]

I'm inclined to think that they should be equivalent yeah. You'd naturally assume that if a function already exists to do something once, then an analogous version for an iterable of the same object is just calling that singular one somewhere.

The problem with making it an equivalent is that the function would no longer be capable of returning the response for the request that sent the statement array.

By the Spec, an LRS should be capable of processing arrays of statements and the example page useWrapper.html seems to do this fine. Are you able to describe the kinds of statements that are being rejected by sendStatements() and accepted by iterated sendStatement() calls?

[brian-learningpool]

Hi @vbhayden, apologies for the delay.

The kinds of statements being rejected by the LRS when calling sendStatements() are the launched and initialized statements. When called in a sendStatement() loop they work fine.

Again, this was only a problem when used with the ADL launch mechanism.

[vbhayden]

Sorry for the late response, especially with such a silly question, but does sendStatements() work when the launched / initialized verbs are excluded?