Course published as AICC will quit reporting status after connection failure.
Oct 11, 2023
I would like to report a bug we have experienced in production last week which I tracked down today. I am the developer responsible for our LMS I do not directly build courses myself.
We had 4 people last week which sent us screen shots of the final score screen that were not marked complete but when reviewing the logs we quit receiving bookmarks from 5% to 80% thru the course as indicated by the score and size of their last bookmark and other log data.
The problem i found is in the `SubmitFormUsingXMLHTTP` function inside the AICCComm.html file. Screen shot attached of the javascript function.
I was able to consistently break the AICC communication by causing a single AICC call to fail by turning off my network adapter and clicking back on slide then re-eneable. It causes the "waitingAiccResponse=true" to never be set back to false so the requests start to queue. If the server responds with an http http 500 the problem does not happen because that is handled inside the onload callback fuction. It only happens on connection failure aka xmlhttp.send() throws an exception.
After breaking it I manually set the variable back to false and got like 30 requests all at once when it flushed the queue.
Adding a try catch around the `xmlhttp.send()` that sets waitingAiccResponse back to false on failure would probably be enough to fix it.
8 Replies
Nice deep debugging Nathan. Hats off to a fellow deep diving developer! Second the recommended change w/the try-catch wrapper
Ok so not actually try catch it's adding an onerror to objXMLHTTP and it does not die.
objXMLHTTP.onerror = function () {
waitingAiccResponse = false;
WriteToDebug("SubmitFormUsingXMLHTTP send failed");
};
It could also queue the failed request but as i see it the queue is really almost more of a liability as you open up the firehose and flood the server with duplicate requests and possible race conditions.
Lets say you really did loose internet for 2 minutes because the power flickered and rebooted your modem. You would really just want the last AICC PUTPARAM not the last 30-300+ the array has no max count check. You really want the last copy of each type GETPARAM, PUTPARAM and EXITAU in that order.
Hi Nathan!
Thanks for reaching out and providing such detailed feedback!
As an initial troubleshooting step, it would be helpful to see if this behavior could be replicated in SCORM Cloud with LMS Debugging enabled. Seeing what the courses are communicating in the background might help to provide more information on what's happening.
If you run into any setbacks with the testing process please let me know and I'd be happy to assist further!
Looking forward to hearing from you!
Just checking you saw there was a screen shot on the code problem on the fist message.
I believe the reason we had the problem with the 4 clients in a small window is because they are located on an island just north of south America so maybe not the most stable internet connection back to America. This would explain why one of the AICC bookmark api calls might timeout or fail. After just a single failure it will not try to communicate with the server because "waitingAiccResponse" it true from that point forward since there is no code to reset it on failure.
This behavior would apply to any course and any platform because with AICC the course communicates directly with the server and the bug is inside AICCComm.html
I patched the course with the code posted above to handle "objXMLHTTP.onerror" and could not reproduce the problem anymore.
I'll see if i can try to generate you a log some time soon but i'm also very behind after loosing most of yesterday tracking this down and verifying.
To duplicate with any AICC course.
1. Launch and go to the second slide. Clicking between the two slide will cause a bookmark request.
2. Disconnect wifi or unplug network from computer and click to the other slide. You should see the http request fail in chrome console.
3. Turn wifi back on or plug network in.
4. You will not get another bookmark on slide change till exit which seems to set waitingAiccResponse back to false and starts to flush the queue. In our case they either clicked the chrome X which sent nothing on exit or we only got the first few events from the queue but not any of the latter ones.
The main problem is that it quits sending in progress in the middle of the course which makes the exit behavior irrelevant.
Attached is the full log file from Scorm cloud.
Hi Nathan,
Thanks for a detailed description of the behavior you're experiencing. I went ahead and opened a support case on your behalf so we can have our support team take a closer look at the reported behavior. I've shared the details of this ELH post in the case, and someone from our team will be in touch shortly!
It was suggested to enable the feature below but that feature does not detect when the AICC api call fails to reach the server for whatever reason. If the server requests completes but for example the server returns an error response HTTP 404 500 that is what's handled. A single api call connection failure causes it to quit communicating with the server because it thinks a request is already in progress and the feature does not detect that type of failure.
https://community.articulate.com/series/articulate-storyline-360/articles/storyline-360-lost-connectivity-alert
Hello Nathan!
Thanks for sharing this information in this post to benefit our community members who may be subscribed.
We have received your email as well, and please expect Mcgem to respond shortly. I encourage you to continue troubleshooting with him so that we can find a fix. Please let me know if you have any questions!