Task editor scroll-sync test fails intermittently in CI

未关闭 适合新手
  • 哪里不对？
#654 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@melonpuff 已经在做这个了。

开始于 2026年11月12日。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
javascript, playwright
领域
testing

调研方向

阅读 tests/browser/task-workspace.test.js 第 599 行附近最后的滚动断言及其前面的等待条件。Issue 指出可能存在竞态：等待条件检查高亮层是否发生过滚动，而在它到达文本区域的新位置之前，这一条件就可能已经成立。更新同步条件，使断言等待三个滚动位置全部匹配，然后运行浏览器测试并确认这些位置一致。

由索引模型根据 Issue 内容生成。

描述

Observed behavior

The browser test "the task editor paints syntax colours and line numbers behind the textarea" (tests/browser/task-workspace.test.js, the final scroll assertion) failed once in CI on a change that does not touch web/. The three scroll positions it compares were [900, 2276, 2276]: the textarea at the 900 the test had just set, the highlight layer and the line-number gutter at 2276. The same job passed on a rerun, and the identical tree had passed in the previous run of the pull request, so the failure depends on timing and not on the code under test.

Expected behavior

The test passes whenever the layers do follow the textarea, and fails only when they do not. A passing run and a failing run of the same tree should not differ.

Reproduction

I have not reproduced it locally, so this is a single observation, not a measured rate.

  1. Run the three-shard browser lane (gates (browser 2/3)) on GitHub Actions for a pull request whose diff does not touch web/.
  2. The test fails when the highlight layer and gutter have not yet followed the textarea to the position the test set (scrollTop = 900).

What I saw: run 42952178222, job 130298787099, head 5736b690e196636785aa06bd3844b4e581d3fae6, one failure, then a pass on rerun of the failed job. How often it happens elsewhere is unknown.

CodeTrial version

Not a runtime report. The failing revision is 5736b690e196636785aa06bd3844b4e581d3fae6 (a pull request that changes skill scripts and their Python tests only).

Environment

  • GitHub Actions, ubuntu runner, gates (browser 2/3) shard of the browser lane
  • Chromium through Playwright, headless

Hypothesis (not confirmed)

After page.fill of the 120-line buffer the caret sits at the end, so the textarea is already scrolled to the bottom and the layers follow it there (2276 here). The test then sets scrollTop = 900 and waits with waitForFunction until the highlight layer's scrollTop > 0. That condition can already be true from the earlier scroll position, so the wait can return before the layers have followed to 900, and the assertion reads the stale 2276 from the layers. Waiting for the layers' scrollTop to equal the textarea's, instead of > 0, would remove the race; I have not tried it.

Sanitized evidence

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
  actual:   [ 900, 2276, 2276 ]
  expected: [ 900, 900, 900 ]
  at tests/browser/task-workspace.test.js:599:12
failed gates: browser-tests
主要语言
Rust
星标
228
派生
150
平均合并
1 天 3 小时
30 天内合并 PR
226

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

sysprog21/codetrial 的其他 Issue

查看 sysprog21/codetrial 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。