Selective "500: Server Error"s when connecting to a LRS to retrieve Tin Can API Statements

[BesseyMatt]

Version
Version 1.5.0

Steps to reproduce the bug
Make a GET request to an LRS ending with ?agent={"objectType":"Agent","mbox":"mailto:XXXXX@gmail.com"}&limit=400 . This worked on the public LRS but not on our LRS.

The Tin Can API Statements look something like this:

{
"version": "1.0.1",
"actor": {
"objectType": "Agent",
"name": "Matt Bessey (Intern)",
"mbox": "mailto:mbessey.int@blizzard.com"
},
"verb": {
"id": "http://adlnet.gov/expapi/verbs/returned",
"display": {
"en-US": "returned"
}
},
"object": {
"objectType": "Activity",
"id": "http://course/100",
"definition": {
"type": "http://adlnet.gov/expapi/activities/course",
"name": {
"en-US": "Introduction to Algorithms"
},
"description": {
"en-US": "This course provides an introduction to mathematical modeling of computational problems. It covers the common algorithms, algorithmic paradigms, and data structures used to solve these problems. The course emphasizes the relationship between algorithms and programming, and introduces basic performance measures and analysis techniques for these problems."
}
}
},
"authority": {
"objectType": "Agent",
"name": "Test LRS",
"mbox": "mailto:hello@learninglocker.net"
},
"stored": "2015-08-28T23:06:35.291100+00:00",
"timestamp": "2015-08-28T23:06:35.291100+00:00",
"id": "210ef87b-ae6e-4c41-9d22-534133c16841"
}

The statements are being saved correctly from what I can tell, they are all there when we view them on our learning locker web interface.

Expected behaviour
The request statement:

GET http://parut912/data/xAPI//statements HTTP/1.1
Content-Type: application/json
Authorization: Basic XXXX...
X-Experience-API-Version: 1.0.1
Host: parut912
Content-Length: 764
Expect: 100-continue
Connection: Keep-Alive

{"agent":{"objectType":"Agent","mbox":"mailto:XXXXX@gmail.com"}, "limit":"400"}

should be returning from learning locker with Tin Can Statements. The request when sent to the public LRS is returning correctly.

The expected response should be like:

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/json
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.4.29
Access-Control-Allow-Origin: http://parut912
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS
Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Requested-With, X-Experience-API-Version, X-Experience-API-Consistent-Through, Updated
Access-Control-Allow-Credentials: true
X-Experience-API-Consistent-Through: 2015-08-31T09:48:20.693700+00:00
X-Experience-API-Version: 1.0.1
Set-Cookie: laravel_session=eyJpdiI6IlpCdEFCb1B4eUF5U3N2OUxCK0pSOFRSODA0bEc4K05NTEM2VUs0U1dFT0k9IiwidmFsdWUiOiJ3WDJUWjNkb3U4TlhcL1B5YU9xREM3QzNcL3l0aWR1OTBxRnRGNzM3a2RJYmluTHFLbmo5SzVZNjZxa0RKamVvaENONmhOUWlEdE5QcnhBMUFBMTc1Z2Z3PT0iLCJtYWMiOiI2NzhlNTQ4N2UxZjk0ZmU2N2M4OTZmZjZjYzc0Njc0MGQxNWM3ZDNiMzg2YzcwOWUzYTRlNzFkOTNkMzYzZWVhIn0%3D; expires=Mon, 31-Aug-2015 11:48:20 GMT; path=/; httponly
X-Powered-By: ASP.NET
Date: Mon, 31 Aug 2015 09:48:20 GMT
Content-Length: 40

["19187cad-cb87-4146-b2b4-020ff6bb85b5"]

Actual behaviour
The server is inconsistent with its return statements. It returns the Tin Can Statements correctly if the user is viewing a video, but the same data cannot be retrieved in our "recently viewed" widget. Currently when the request is sent to our LRS it returns with a 500 server error

HTTP/1.1 500 InternalServerError
Cache-Control: no-cache
Content-Type: application/json
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.4.29
System.Net.WebException: "The remote server returned an error: (500) Internal Server Error."
Date: Mon, 31 Aug 2015 09:48:20 GMT

Server information
- - -

Client information
OS: Windows 7
Browser: Chrome version 43.0.2357.134

Additional information

Hey everybody,

First off, I’m new with working with a LRS and have recently begun working on a project that is using a LRS to store Tin Can API statements. The original creator of my teams application has since moved on, so I’m here trying to make sense of what is going on in the application.

The application seems to have been working great until about 6 months ago when the application started to be selective with what requests correctly connected to the LRS and which did not. As I mentioned earlier, we are using an LRS to store Tin Can API statements (for those that may not be familiar with Tin Can, it’s an API used to store data on who is watching embedded videos and saves and restores the last viewed timestamps of videos for those users, among other things). It looks like the last viewed timestamps are being retrieved with no issue while watching the video, however we have a “recent activity” widget that is trying to pull the same data out of the LRS and is returning with a 500 Server Error.

The application hasn’t been changed for about a year (when it worked just fine) but about 6 months ago we began to get these 500 server errors. I’ve tried using the same request statements that we are trying to use on the Public LRS and it seems to be working fine and the connection strings are working as well since the data is being retrieved in some situations but not all of them.

I’m wondering if anything changed within the source code a few months ago that I’m not aware of that might require me to change something in the application to correctly connect to the LRS and if anyone else has fixed a similar issue.

Thanks for your help!

Matt

[ryasmi]

Hi @BesseyMatt, thanks for reporting this bug and using our template. We will now try to reproduce your issue 👍

[ryasmi]

Hi @BesseyMatt, after another look at your issue, please could you edit it after reading the comments below.

• The steps to reproduce the issue need to be expanded as if it's being done on an LRS without statements, if I just follow your step I get nothing. You need to show what statement you're putting in.
• The expected behaviour should describe what HTTP response you expect back (in terms of headers and contents).
• The actual behaviour should describe what HTTP response you actually get back (in terms of headers and contents).

[ryasmi]

Could you also run php artisan migrate from the root directory of your Learning Locker installation.

[BesseyMatt]

Hey @ryansmith94 So I added in as much info as I could. Since I'm new to working with Learning Locker, I'm not exactly sure what you are looking for with the steps for reproducing " need to be expanded as if it's being done on an LRS without statements." If you could provide more details on what you are looking for that would be awesome. I did my best to fill out the expected and actual behavior--hope that helps.

As far as the php artisan migrate command when we ran it, it only outputs “Nothing to migrate”.

Thanks for your help and let me know what other info I can get for you.

[ryasmi]

Hey @BesseyMatt, thanks for that. No worries, regarding the steps to reproduce I meant that we needed more details to reproduce the state of your LRS. For example, you have inserted statements that you expect to be returned, but we don't know what statements you inserted. Sometimes there is a misunderstanding rather than a bug so these details help us to reproduce your problem and ensure there are no misunderstandings.

Could you please try to run php artisan migrate --env=local?

You're very welcome. Will do, thanks for your co-operation.