When implementing xAPI tracking in a product or testing a data source developed by somebody else, it can be helpful to see a record of any error messages for xAPI statements rejected by Watershed. The Error Log page allows you to do just that.
- User Types
- Global Admins can use the Error Log
- Available on plans (Essentials, Analyst, CLO, and Enterprise).
- Experts can use this feature.
Getting to the Error Log
To access the Error Log, choose Error Log from the Data menu.
Errors are recorded when Watershed receives an interaction statement (xAPI statement) batch that contains an invalid statement. They explain the reason why the statement was rejected so that a developer can fix the problem.
Please note:The Error Log normally only records errors relating to xAPI statements. Errors relating to invalid authentication credentials, incorrect endpoint URLs or requests that do not contain statements at all may not be recorded here.
Let’s look at the information available for each error.
The screenshot above shows an error that has been expanded to show more detail. Errors are listed with the most recent first. Unexpanded errors include the date and time that the error was recorded and the error message that was returned. Expanding an error also displays the following data:
The HTTP error code.
The HTTP headers received in the request.
The complete JSON of the statement(s) included in the request.
The type of request that was made and the endpoint it was sent to.
There are some error codes that appear in the error log more commonly than others. Let’s explore some of these common errors and how to handle them.
400 Bad Request
A status code of 400 means that there is something wrong with the request that’s been sent. This can either be an error with the request headers or with the xAPI statement itself. Normally the error message will provide helpful advice on what specifically the error is, but in cases where Watershed was unable to parse the statement at all, you may just get a generic error. In these cases you will need to check the statement carefully against the xAPI specification and working statements to identify the issue.
If the error message reads “Unauthorized” and the status code is 401, that means the credentials used to send the request are not valid. This could be because:
- There’s a bug in the application sending the data and the authentication header is not being set correctly or is not being set at all. Note that for security reasons we never include the full authentication header in the request.
- The application sending the data has been misconfigured. Check the credentials and try again.
- The credentials used by the application have been deleted or disabled. If this is a new error for an application that used to work, this is a good thing to check.
- You’re using session based authentication and the session has expired.
Search and Filters
Data sources should not normally generate errors on an ongoing basis, so you can normally simply look at the most recent error messages during development or testing of a particular data source. If you need to find a specific error or need to look back to a particular date and time, you can use the text search and date filters to filter errors.
To search for a word or term, simply enter it into the search box. This will filter and highlight errors that contain the term in any of the fields, including the error message and statement itself.
To filter by a date range, simply click in the Since timestamp and/or Until timestamp fields and select dates and times using the datepicker.
Once you have dealt with an error, you can click the Archive button to move the error to the Archived Errors tab. You can also Archive all errors to clear the list. Archived errors can be viewed and unarchived at any time from the Error Log Archive page accessed by clicking Error Log Archive at the bottom of the page.