Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Reset or Show pressed while the task cube is turning does not stick

Open
#558 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@YEH-YU-YANG is already working on this.

Since Oct 30, 2026.

  • #560 by @YEH-YU-YANG — open

Assessment

This issue has not been assessed yet.

Description

Observed behavior

In a task that names the cube explainer, such as the default rubik task, Reset and Show do not hold when they are pressed while a turn is still swinging. The cube first shows the solved cube or the typed position, and then the turns still queued land on it. Applying R U R' U' and pressing Reset during the first turn ends on 21375642212111 with "Moves so far: R U R' U'" instead of the solved 12345671111111. Showing 21653471111312 the same way ends on 12673452213311, a different position from the one typed. docs/task-mode.md says a code typed from the public cases changes all three views, so a learner checking a public case against the cube is shown the wrong position.

Expected behavior

Reset ends on the solved cube and Show on the typed position, whatever was still turning; the turns asked for before either button is pressed are dropped.

Reproduction
  1. Open a task that names the cube explainer and start the attempt, so the cube is shown.
  2. Type R U R' U' into the cube's algorithm box and press Apply.
  3. While the first turn is still swinging (each turn takes about a quarter of a second), press Reset.
  4. Wait a second: the cube turns again, the history reads "Moves so far: R U R' U'", and the code reads 21375642212111.
  5. Repeat with 21653471111312 typed into the position box and Show pressed in step 3: the code ends on 12673452213311.

I ran these steps in Chromium on the task page as tests/browser/task-workspace.test.js serves it, with that file's stub task agent, camera and face detector; the cube is the page's own web/cube-view.js.

CodeTrial version

cargo run -- --version does not build here: the webrtc-sys C++ build fails with this machine's toolchain. The page comes from a checkout of main at 3bbbcf5 (3bbbcf5d924bfb22ececc82ca2543d71f810b225).

Environment

OS: Ubuntu 24.04.3 LTS
Browser: Chromium 156.0.8078.4 (the Playwright build)
Language: not applicable
Interview loop: task mode, the default rubik task
Problem: not applicable
REACTO or STAR step: not applicable
Reconnect: not applicable

Sanitized evidence

The task cube on main: R U R' U' applied, Reset pressed during the first turn, and two seconds later the cube has turned again and reads "Moves so far: R U R' U'"

run() queues each turn on busy and applies it after await swing(move) to whatever state is current by then (web/cube-view.js L390-L407). The Reset handler (L257-L262) and the Show handler (L304-L314) assign state and history at once, and neither cancels nor waits for the turns still queued, so those land on the replacement cube. The cube's state stays in the page; nothing is sent to the runtime, Jim or the review.

A fix that drops the turns asked for before a Reset or Show, with a browser test that fails on main, follows as a pull request.

Public data confirmation
  • I removed credentials, session tokens, candidate recordings, and personal interview content from this public report.
Dominant language
Rust
Stars
215
Forks
141
Avg merge
1d 12h
Merged PRs (30d)
232

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sysprog21/codetrial

All issues in sysprog21/codetrial

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.