Interactors

An interactor is a program that talks to the participant's solution while it runs. Rather than handing the solution a static input file, the interactor starts on every test just before the solution does, with the two processes' standard input and output wired to each other: whatever the solution prints, the interactor reads, and whatever the interactor prints goes to the solution's input.

That is what makes a guessing game possible — the solution proposes a number, the interactor answers "too low" — and, more generally, any problem where the data a solution receives depends on what it has already asked.

The Interactor row appears on the problem's Testing tab only when the problem type is Interactive. If you cannot find it, open Testing → Configuration and change the type first. You need permission to write problems.

The row shows the interactor's runtime, or unset. Its editor takes a runtime, additional files and the source, with Save and a Reset that removes the interactor after a confirmation.

Exit codes

The interactor's exit code is how it reports what happened:

Exit code

Result

0

The interaction succeeded. The checker then grades the test.

1

The test fails as a wrong answer.

anything else

The whole submission fails as a system error.

Exit code 0 does not mean the test passed — it means the conversation completed. Grading still goes through the checker, which is why an interactive problem normally has both. A problem with neither a checker nor an interactor cannot grade anything.

Test data for interactive problems

The stored input and answer of an interactive test are usually instructions for the interactor — the hidden number, the shape of the adversary — rather than anything a participant would recognise. That is fine for judging and unhelpful in the statement.

The per-test Override input shown in statement and Override answer shown in statement fields exist for exactly this: they change what the Examples section displays without touching what the judge feeds the interactor. See Test cases.

Repeated runs

Testing → Configuration has two settings that matter here. Run count is how many times each test is run, and Interactive followup makes the interactor take part in the second and subsequent runs.

Writing the protocol down

Participants cannot guess the conversation. The Interaction section of the statement is where the protocol belongs: what the solution sends, what it gets back, in what order, how the exchange ends, and how many queries are allowed.

Secret interactors

An interactor marked secret — common in imported problems — cannot be displayed. The editor offers Override, which replaces it with whatever you write. The original is not recoverable through the console.