Calling LRS .saveStatement with an object but not a TinCan.Statement doesn't cause error

[brianjmiller]

Need to investigate but the following didn't result in an error in the callback:

lrs.saveStatement(
    {
        actor: {
            mbox: "brian.miller@scorm.com"
        }
    },
    {
        callback: function (err) {
            console.log("Priming statement sent");
            if (err !== null) {
                console.log("Priming statement failed: ", err);
                process.exit(1);
            }

            // getting here and shouldn't
        }
    }
);

[FishHooks]

@brianjmiller would it make sense to try constructing a TinCan.Statement object from the object passed, or should we be strict on this and only accept TinCan.Statement objects?

[brianjmiller]

Actually I now suspect this is because of the dumb default of allowFail. Unfortunately didn't record how the TinCan.LRS object was constructed, but it makes sense that there wouldn't be an error in the callback if allowFail is set to true (which is the dumb default, one of the items on the roadmap #110). Though in this case perhaps even for allowFail set to true we could fail because it isn't the communication with the LRS that is failing, it is an improper use of the library.

I've thought about auto-constructing a statement object, but I don't know that there is a reason to change it for this issue, the larger problem was that even in that case it should still fail.