Final submitted code is not preserved in Past attempts reports

Update after retesting

After retesting, I confirmed that the report shown immediately after the interview correctly preserves the final submitted code.

The code is only missing after returning to the lobby and reopening the same interview from Past attempts.

In that case, the reopened report shows:

Your final code (C)
(final code was not saved)

Therefore, this issue is better treated as a request to preserve the final submitted code in interview history, rather than a bug in the immediate post-interview report.

Steps to reproduce

Complete a coding interview with code in the editor.
Confirm that the report shown immediately after the interview contains the final code.
Return to the lobby.
Open the same interview from Past attempts.
Scroll to Your final code (C).

Current behavior

The reopened report shows:

(final code was not saved)

Requested behavior

Preserve the final submitted code in interview history so that reports reopened from Past attempts can still display it.

Where did you open the report? The report shown right after an interview, and the .md downloaded from it, carry the editor contents (web/interview.js:2646 and :2697). A report reopened from Past attempts never does: the saved history entry has no code field (saveHistory in web/interview.js), so the lobby renders the fixed text "(final code was not saved)" for every attempt (web/app.js:1128) and its download passes no code either (web/app.js:1191). If you only see it under Past attempts, this is that design, and the request becomes keeping the final code in history, which needs a decision on the local storage budget in web/history.js. If the report on the interview page itself shows it, that is a bug: please add the output of codetrial --version and whether that report was a normal evaluation or the offline summary.

@Mofengyi9213

@Mofengyi9213 A reminder of the question from 2026-10-03: where did you open the report that lacked your final code? If only under Past attempts, that is the current design (web/app.js:1128) and this becomes a request to keep the final code in history. If the report on the interview page itself, right after the interview, lacked it, that is a bug: post the output of codetrial --version (it prints codetrial 0.1.0 (<sha>)) and whether that report was a normal evaluation or the offline summary. This issue closes as not planned if nothing arrives by 2026-10-17; posting the answer afterwards reopens it.

Thanks for the clarification. I retested the behavior.

The report shown immediately after the interview correctly includes my final code.

The code is only missing after I return to the lobby and reopen the same interview from Past attempts, where it shows:

Your final code (C)
(final code was not saved)

So this matches the current behavior you described rather than a bug in the immediate post-interview report. I would like to reframe this issue as a request to preserve the final submitted code in interview history.

For version information, the binary I used was downloaded on 2026-09-27 at 23:12 +0800, and the affected reports show:

Contract: bundle 17

The binary predates the current codetrial --version behavior. Running it with --version returns:

--version requires a value

and -V returns:

unknown agent mode: -V

So I cannot provide an exact build SHA from this binary.

For version information, the binary I used was downloaded on 2026-09-27 at 23:12 +0800, and the affected reports show:
`Contract: bundle 17`

Build from source instead.

I rebuilt CodeTrial from the current source and retested the behavior.

cargo run -- --version reports:

codetrial 0.1.0 (cb5b492)

With this source build, the report shown immediately after the interview correctly includes the final code.

However, after returning to the lobby and reopening the same interview from Past attempts, the report still shows:

Your final code (C)
(final code was not saved)

So the current source build still has the same Past attempts behavior.

Since this is the current design rather than an immediate post-interview report bug, I would like to treat this as a request to preserve the final submitted code in interview history.

Since this is the current design rather than an immediate post-interview report bug, I would like to treat this as a request to preserve the final submitted code in interview history.

Provide a more thorough analysis and identify the root cause. As an engineer, you are expected to solve real-world technical problems.

Root cause on main at 6b6cdfe: the final code is never written to history, and the lobby would drop it even if it were.

web/interview.js:3117: saveHistory builds the entry from the report and its metadata only, with no code field. The report shown right after the interview has the code because buildMarkdown (web/interview.js:3149) reads currentCode() from the live editor.
web/progress.js:68: normalizeProgressEntry copies a fixed set of fields into each attempt, so a stored code would not reach the lobby.
web/app.js:1373: the reopened report passes the literal "(final code was not saved)".
web/app.js:1454: downloadSavedReport passes code: null, which web/render.js:658 renders as the same placeholder.

Constraints a fix has to respect:

web/history.js:8: the review store keeps up to 500 reports within 164 KB, and boundedReviews skips a report that does not fit. Code in every review would let one long solution push its whole report out and would reduce how many older attempts can reopen.
src/web/mod.rs:52 caps an account save at 64 KB, and src/accounts/reports.rs:114 stores the payload as given, so a code field would be kept server side.
README.md:48 says code snapshots stay in memory unless recording is enabled.

Proposed change:

Add code to the entry in saveHistory.
Keep it in the short local history (the newest 20 attempts) and strip it when the review store is built, so the 164 KB budget is unchanged. Attempts older than the newest 20 keep the placeholder.
Leave it out of the /api/reports body.
Carry code through normalizeProgressEntry as a string or null, and pass it at web/app.js:1373 and web/app.js:1454.
Tests: a saved entry carries the code; the review store and the account request do not; an attempt within the newest 20 reopens with its code, in the page and in the download; an entry without code still renders the placeholder.

One decision blocks the account half: should the account copy carry the code as well? It would let Past attempts show it on another device, but it changes what README.md:48 says the server keeps. Without that, the change stays local only.

Keep the final code in the local history

@Mofengyi9213

@Mofengyi9213 Nothing more is needed from you here. The root cause @Patriciaath999 posted on 2026-10-15 is what PR #321 implements: saveHistory keeps the final code in the short history (codetrial_history, the newest 20 attempts), so a report reopened from Past attempts and its .md download show it, while older attempts keep the placeholder and the 164 KB review store is unchanged. Its merge closes this issue.

@Patriciaath999 #321 conflicts with main, and the rebase requested there on 2026-10-21 and 2026-10-23 is the next step. Once it merges, @Mofengyi9213 can retest on a build from source of main at or after the merge commit: the code showing under Past attempts means this is done; still seeing "(final code was not saved)" means post the cargo run -- --version line here.

Keep the final code in the local history

Navigation Menu

Repository navigation

Final submitted code is not preserved in Past attempts reports #221

Update after retesting

Steps to reproduce

Current behavior

Requested behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Final submitted code is not preserved in Past attempts reports #221

Description

Update after retesting

Steps to reproduce

Current behavior

Requested behavior

Activity

jserv commented on Oct 3, 2026

jserv commented on Oct 9, 2026

Mofengyi9213 commented on Oct 10, 2026

jserv commented on Oct 10, 2026

Mofengyi9213 commented on Oct 10, 2026

jserv commented on Oct 10, 2026

Patriciaath999 commented on Oct 15, 2026

jserv commented on Oct 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions