Repository navigation
Description
Problem
README.md and docs/interview-length.md say CODETRIAL_DURATION_MIN is the length preselected in the lobby for a candidate who does not choose. An operator who sets CODETRIAL_DURATION_MIN=30 and starts codetrial web still gets 45 preselected, and, from reading token_duration_min, a /api/token request with no durationMin would also be given 45.
Current behavior
Reproduced on a release build of upstream/main e87cc4d (the line numbers below were checked against it) with a placeholder LiveKit config and no provider keys:
make build
CODETRIAL_DURATION_MIN=30 ./target/release/codetrial web --config cfg.env --web-addr 127.0.0.1:3100
curl -s 127.0.0.1:3100/api/session/api/session returns {"candidateVideo":null,"deviceLogin":false,"guestModeAvailable":false,"loginRequired":true,"maxDurationMin":90,"signedIn":false}, with no default length.
After the lobby page had loaded in a browser and its scripts had run, the duration buttons were:
data-duration=30 selected=false disabled=false
data-duration=45 selected=true disabled=false
data-duration=60 selected=false disabled=false
With CODETRIAL_DURATION_MIN unset, /api/session and the served page are dentical. The browser check was made signed out, since the placeholder config cannot sign in. /api/token was not called for the same reason; its behavior below follows from token_duration_min taking no configured default.
src/config.rs:471loads the value intodefault_duration_min.- The only readers of that field are
src/main.rs:810(check-gemini) andsrc/web/setup.rs:947(setup probe bootstrap). Neither reaches a candidate. src/web/auth.rs:543-587:/api/sessionreportsmaxDurationMinbut no default length.web/index.html:1766hard-codesclass="duration-button selected"on the 45 minute button.src/web/token.rs:432: a missingdurationMinbecomes the constantDEFAULT_DURATION_MIN, not the configured value.- The value does take effect in one place:
src/main.rs:1238(interview_duration_min) feeds the recording cap check.
Desired outcome
Either of the following, whichever the maintainers prefer.
A. The setting reaches the lobby. The configured length is the one preselected in the lobby, and the one used when a token request names no length, limited by duration_ceiling. This matches what README.md and docs/interview-length.md already say.
B. The setting stays operator-only. CODETRIAL_DURATION_MIN keeps affecting only check-gemini, the setup probe and the recording cap check, and the README, docs/interview-length.md and config/codetrial.env.example say so instead of promising a preselected length.
Proposed scope
For A, one PR:
src/web/auth.rs:/api/sessionalso reports the configured default length.web/app.js: select that button when the page loads, beforeapplyDurationCeiling, so a default above the recording cap still moves down. A length the candidate chose earlier is not overwritten.src/web/token.rs:token_duration_minuses the configured value instead ofDEFAULT_DURATION_MINwhen no length is named.- Tests:
/api/sessionreports 30 when configured and 45 when not; a token request withoutdurationMingets the configured value, still limited by the recording cap; a browser test shows which button is preselected and that a remembered choice wins.
For B, one PR that edits the three documents above and removes the claim.
Open question
The lobby offers 30, 45 and 60 minutes, while the endpoint accepts 10 to 90. For A, how should a configured value that is not one of the three buttons (for example 20 or 75) behave: snap to the nearest button, or leave the 45 default?
Acceptance criteria
For A:
- With
CODETRIAL_DURATION_MIN=30,/api/sessionreports 30 and the lobby shows 30 selected; with it unset, 45 as today. - A
/api/tokenrequest withoutdurationMingets the configured value, still limited by the recording cap. - A configured value outside the three buttons follows the answer to the open question, and
docs/interview-length.mdstates it. ./scripts/test.shpasses.
For B:
- No document says the setting preselects a lobby length.
./scripts/test.shpasses.
Related
Not a duplicate of #16 or #17 (recording cap vs interview length), which are closed and do not touch the default.
I would like to implement this myself, whichever of A or B the maintainers choose. I will wait for the issue to be assigned to me before opening a pull request, and I will keep the change to one pull request with the tests listed above.
Activity
RWong04 commentedon Nov 4, 2026
Thanks for assigning this. I will go with option A: /api/session reports the configured length, the lobby preselects it, and /api/token uses it when none is given. A value that is not one of the three buttons snaps to the nearest one. Please tell me if you prefer B.
jserv commentedon Nov 4, 2026
Go ahead with option A. Meanwhile, review the API endpoints and remove any that serve no useful purpose.
RWong04 commentedon Nov 4, 2026
Understood. I will keep this PR to option A and send the endpoint review as a separate PR, listing each endpoint I propose to remove and its callers. Please tell me if you want it in this PR instead.
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
jserv commentedon Nov 6, 2026
@RWong04 Keep #584 to option A. Send the endpoint review as its own PR, listing each endpoint you propose to remove and its callers, as you describe.
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length
Preselect the configured interview length