Client Error Reports

Artemis does not send errors to an external error tracking service. When the client hits an unexpected error, it reports it to the Artemis server it was loaded from, and the server writes it to its log. There is no database table for it and nothing else to operate: the log is the only place the reports end up, and the log rotation you already run decides how long they are kept.

What is reported

The client reports an error that nothing else handled, for example an exception in a component, and the errors that the code of Artemis reports deliberately when a state should never happen, such as an unknown question type. A failed request with a status from 400 to 499 is not reported, because it is expected and the user is told where it happens. A failed request with a status of 500 or higher is reported.

A report contains the message and the stack of the error, the path of the page without its query and fragment, the client version, the browser as sent in the User-Agent header, whether the sender was signed in, and a few short labels and values that describe the situation. It never contains the login of the sender. The client sends the same error at most once per minute and at most ten reports per minute from one page, so a defective component cannot flood the server.

Where to find the reports

The server logs every report with the logger of ClientErrorReportService and a message that starts with Client error report. The log level follows the severity of the report: ERROR for an error, WARN for a recoverable problem and INFO for a hint. The stack follows on the next lines, each starting with a tab.

ERROR ClientErrorReportService : Client error report [version=9.8.0, url=/courses/1/exams/2, authenticated=true, userAgent=Mozilla/5.0 ..., tags={feature=quiz}, extra={exerciseId=42}]: Unknown question type: foo
	Error: Unknown question type: foo
	    at ...

Every node that receives a report writes it to its own log, so search the aggregated log of your deployment for Client error report to see the reports of all nodes together.

Privacy

The endpoint is open to clients that are not signed in, so the server does not trust what it receives. Before an entry is logged, every value is shortened to its limit, and control characters and line breaks are removed so that a sender cannot forge a log line. Query strings and fragments of the page url are dropped. A failed request that a client reports is described by its status and its path, without its query and without the body of the response.

The server removes these kinds of personal data from the message, the stack and the additional values of a report, and nothing else:

• email addresses
• user= assignments
• User{...} dumps, also one that the client cut off before the closing brace
• the value of a field named userLogin, studentLogin, login or username in serialized data, as in {"userLogin":"ge12abc"}
• the participant in the url of a repository

A name, a student identifier or any other personal data that is written into a message in another form stays in the log, exactly as the client sent it. The server cannot recognize it, so do not put it into a message or into the additional values of a report, see Reporting unexpected errors. The log of Artemis is only readable by those who operate it.

Rate limit

An error often happens where nobody is signed in, for example on the login page, so the endpoint POST /api/core/public/client-errors needs no authentication. Every report writes a log entry, so a client that is not authenticated is limited per address. Reports of signed-in users are not limited by the server, as the client already limits them. A request that exceeds the limit is answered with status 429 and is not written to the log of Artemis above debug level, because a limit that bounds the log must not write a line for every request that it rejects. Your reverse proxy still records it in its own access log.

artemis:
  rate-limiting:
    enabled: true
    client-error-report-requests-per-minute: 60

ℹ️

Information:

This limit cannot be switched off. Unlike the other rate limits, it also applies when artemis.rate-limiting.enabled is false or the rate limit feature is toggled off, because anybody who can reach the server could otherwise fill its log through this endpoint. Only an address in artemis.rate-limiting.exempt-addresses is not limited, see Security.

The limit counts the address of the TCP peer as Tomcat resolved it. Artemis does not read X-Forwarded-For for this limit, because a sender could put any address into the header and receive a new budget for every request. Tomcat believes the forwarding headers only of the proxies in server.tomcat.remoteip.internal-proxies, which by default are the private networks. If your reverse proxy is not in a private network, all clients have the address of the proxy until you name it there, and then they share one budget of 60 reports per minute, which drops the surplus reports. The other rate limits of Artemis still use the first value of X-Forwarded-For.

The limit is shared by all clients behind the same address, for example a lecture hall behind one NAT. The default of 60 reports per minute leaves room for that. If the limit is exceeded, the server answers with status 429 and the client does not retry.

Replacing Sentry

Earlier versions of Artemis could send errors, traces and performance data to a Sentry server. That integration is gone, and the properties sentry.dsn and info.sentry.dsn are ignored. Remove them from your deployment configuration.