Errors and timeouts

Three different things can go wrong, and your users should see different messages for each: the request was refused, the program did not compile, or the program ran too long.

Status codes

A 401 usually means the client ID or secret is wrong, or a socket token has expired. A 429 means the allowance is gone until it resets.

A failed program still returns 200

This is the one that catches people. If the program does not compile, the request succeeded. You get 200, and the compiler's message is in output.

So a 200 does not mean the program worked. It means we ran it and can tell you what happened.

When you asked for compileOnly, the response includes compilationStatus: 0 when it compiled, 1 when it did not.

On failure the response carries an error field alongside statusCode, rather than output.

Timeouts

A program that runs too long is stopped. The request still returns 200, and output explains what happened, so your user sees a reason.

Three things cause most timeouts:

• The program is waiting for input that never comes. Over REST you must send everything the program reads in stdin. If it prompts and you sent nothing, it waits until it is stopped. This is the most common cause.
• The program has an endless loop. The user's own bug.
• The work is genuinely heavy. Contact support if your users need more execution capacity.

If your users write programs that ask questions, use a WebSocket connection instead, so they can answer while it runs.

What to show your users

• The program was wrong. Show the compiler output. This is the user's to fix, and by far the most common case.
• The program timed out. Say so plainly. Users assume a crash otherwise.
• The request was refused. That is your problem, not theirs. Tell the user the service is unavailable.

The third one is what reaches support as "the site is broken". A message that separates it from a code error saves the ticket.

What next

What a credit is, and what each call costs, is on the credits and pricing page.