conformance: probe environment (SPEC 8.1) and driven scenarios - the checker sees what a client does with each action - #8
Merged
Conversation
…the checker sees what a client does with each action and how it handles closes The passive checker watched one connection and could not tell chunk-summed reward, terminal observations, time-major order, metadata-first, the close reasons or text frames from their violations. With --probe the client runs a probe env whose observation counts steps and echoes the applied action, and the checker drives the connection: it speaks late, sends a 2 MiB metadata frame, closes for a resync, stops the run, and answers with a text frame. raw_client.py implements the probe env, and its --bug option breaks each clause in turn; tests/test_conformance_probe.py checks that each is named.
…fter Found by the probe checker itself, on Linux, in about one run in two of the resync scenario: when the server's resync close arrived while the feedback was being sent, the send raised, the reset after it never ran, and env 0 carried its finished episode onto the next connection (t = 7, 11, 15 for an episode of 3). The packed feedback already holds the terminal observation, so resetting first changes nothing the server sees.
Member
Author
|
Added one commit. On Linux the resync scenario failed the conforming client about one run in two, and the checker was right to fail it. When the resync close arrived while the client was sending its feedback, the send raised, and the reset after it never ran. Env 0 then carried a finished episode onto the next connection, reaching t = 7, 11 and 15 in an episode of 3. The client now resets ended episodes before sending; the packed feedback already holds the terminal observation. After the fix, the probe tests passed five runs in five on Linux. |
…s a 7.6 violation; raw_client --bug stale-chunk plugrl-env-client failed the resync scenario this way: after reconnecting it fed back chunks answered on the old connection, which the checker reported under 4.3. On a reconnected connection, feedback for an env that was never given an action there is now named for the clause it breaks. The new stale-chunk bug does exactly that, and the test expects the 7.6 clause.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SPEC.md section 8 lists what a client must do. The checker watched one well-behaved connection, so it could not tell several of those clauses from their violations:
A client breaking all of these still printed "no violations", and SPEC.md said so.
The probe environment (new SPEC 8.1). A client under test runs
nprobe envs instead of its real ones. Envicounts the steps of its episode instates["t"], echoes the action it applied last instates["a"], pays 1 per step, and terminates att = 3 + 2(i mod 3). The checker sends actions whose values encode their position (10000 k + 10 j + d). From each feedback it then works out:H, and the reward must equal them;t = 0.Driven scenarios (
--scenario basic|resync|text|all). The checker drives the connection instead of watching it:permessage-deflate;plugrl-server-stop, after which the client must exit 0 and not reconnect.plugrl-server-resyncjust after sending an action. The client must reconnect, and start the new connection with an infer, not the feedback it was holding.Passive mode is unchanged and remains the default, so the C++ client's CI steps are untouched.
Proving each check works.
examples/raw_client.py --probeimplements the probe env, executes chunks as SPEC 5.3 says, and handles the close reasons. It passes all three scenarios with the existingtextnote. Its--bugoption breaks one clause at a time:early-infer,compress,frame-cap,float32,env-major;last-step-reward,reset-in-step,resend-feedback,stale-chunk,ignore-stop,ignore-text.tests/test_conformance_probe.pyruns the checker against each bug and expects it to name that clause. All eleven are caught, and the conforming client passes.What probe mode still cannot check is listed in SPEC 8:
env_ids, which must equalenv_indicesanyway;CI.
conformanceextra, so the new tests run rather than skip.Local run: 42 passed (30 existing, 12 new).
It has already found two real bugs.
stale-chunkbug reproduces it.Next: the C++ reference client gets the probe env, and plugrl-env-client gets a
probe-v1env so the main client can be graded the same way.