mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-11-07 06:19:43 -10:00
易良andQwen-Coder
c666ec1a0a
* fix(live): restore Windows filesystem compatibility
* fix(ci): restore Windows test baseline
* fix(ci): keep release-age excludes internal and re-arm two witnesses
- pnpm-workspace.yaml: drop '@tybys/[email protected].4' from
minimumReleaseAgeExclude. scripts/tests/package-scripts.test.js pins
that list to internal, version-independent entries. The exclusion is
also inert: minimumReleaseAge is not configured anywhere in the repo,
and pnpm-lock.yaml records `overrides` but not minimumReleaseAgeExclude
-- so the '@tybys/wasm-util': '0.10.4' override stays, because dropping
it would desync the lockfile and fail --frozen-lockfile.
- web-shell-brand.test.ts: build the swapped-file fake as BigIntStats.
Production compares bigint fields with a bare `!==`, so a number-backed
fake tripped `dev` first and the perturbed inode was never reached;
removing the perturbation now turns the test red again.
- run-qwen-serve.test.ts: '0' is unresolvable on Windows (getaddrinfo
ENOTFOUND 0), so the wildcard case keeps '0.0.0.0' and witnesses the
socket rather than a spelling: the operator typed port 0, so the report
must carry the ephemeral port the listener actually got. Spelling
normalisation stays pinned platform-independently in
remote-quickstart.test.ts.
- artifact-snapshots.ts: revert the readdir hoist to main. It is
behaviourally inert (the catch rethrows ENOENT on the operationId path
either way), has no test and no Windows link.
Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmu07e78o2w
* fix(ci): restore the load-bearing release-age exclude, keep the witness fixes
The previous commit dropped '@tybys/[email protected].4' from
minimumReleaseAgeExclude to satisfy scripts/tests/package-scripts.test.js:390,
on the reasoning that the entry was inert because minimumReleaseAge is not
configured in this repo. That reasoning was wrong and CI measured it: the gate
is enforced by pnpm itself, not by repo config, so removing the exclude failed
'Install frozen pnpm worktree dependencies' on all three platforms with
Lockfile failed supply-chain policy check (1975 entries)
@tybys/[email protected].4 was published at 2026-09-13T08:00:13.464Z,
within the minimumReleaseAge cutoff (2026-09-12T20:03:50.286Z)
(run 34779568628; Install was green at 6099768ffb, which carries the entry).
Restoring the line makes pnpm-workspace.yaml byte-identical to that head again.
The three other changes from that commit are kept, since they are independent
of the exclude and were green in run 34779568625 (Test 18m58s, Lint & Static
12m36s, Integration no-AK 7m8s): the web-shell-brand.test.ts BigIntStats fake
that re-arms the inode witness, the run-qwen-serve.test.ts socket witness
replacing the tautological '0.0.0.0' assertion, and the artifact-snapshots.ts
revert to main.
This leaves the package-scripts.test.js assertion red exactly as it was before
this round. That is now a measured conflict rather than an open question: the
repo test pins the exclude list to internal, version-independent entries, while
pnpm needs a version-pinned exemption for a package published the same day.
Resolving it means either dropping the '@tybys/wasm-util': '0.10.4' override and
regenerating both lockfiles so an older, age-compliant version resolves, or
relaxing the invariant to admit external version-pinned excludes. Both are
supply-chain policy calls for the author/maintainer, so neither is made here.
Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-closeout/jmu07e78o2w
* fix(ci): pin @tybys/wasm-util to the age-compliant 0.10.3 instead of exempting it
Test (ubuntu-latest, Node 22.x) failed at scripts/tests/package-scripts.test.js:390
(run 34781999892), which pins minimumReleaseAgeExclude to internal,
version-independent entries, while the previous head carried
'@tybys/[email protected].4' there to satisfy pnpm's minimumReleaseAge gate. The two
looked mutually exclusive, but only because the pin chose the newest release.
@node-rs/jieba-wasm32-wasi pulls in @napi-rs/[email protected], which accepts
^0.10.3, and 0.10.3 was published 2026-06-23 -- well outside the 24h window that
rejected 0.10.4 (published 2026-09-13T08:00:13Z). So the pnpm override now pins
0.10.3, the exclude entry is dropped, and both lockfiles follow: package-lock.json
must lock the same version or scripts/check-lockfile.js's "pnpm lockfile against
package-lock.json" agreement gate fails, which also reddens the two check-lockfile
fixture branches in package-scripts.test.js because they copy the real lockfiles.
The pin lives on the pnpm side only, mirroring how the typescript pins already
diverge; npm has no release-age gate, so no package.json override is added and the
nested @tailwindcss/oxide-wasm32-wasi copy of @tybys/wasm-util is left alone. Once
0.10.4 ages out of the window, a maintainer can drop the override from both sides if
nothing else needs the pin.
Verified locally: pnpm 11.24.0 `install --lockfile-only` reports "Lockfile passes
supply-chain policies (1975 entries)"; scripts/tests/package-scripts.test.js 49
passed / 1 skipped (was 3 failed); scripts/tests/check-lockfile.test.js 14 passed;
prettier --check clean.
Co-authored-by: Qwen-Coder <[email protected]>
Patrol-Run: qwen-pr-conflict/jmu0ce8qb32
* fix(ci): handle expected Windows socket reset
* fix(ci): make Windows regression tests portable
* fix(ci): make script tests portable on Windows
* test: re-arm four witnesses the review round found vacuous or over-gated
Each of these was measured, not argued; the mutation named in every case is
the one that used to leave the suite green.
- no-follow-open.test.ts: add the >2^53 identity case. Removing
`{ bigint: true }` from all four production stat call sites left 17/17
green, so the Windows-precision conversion this PR exists for was
unwitnessed. The fixture uses 2^60 offsets, where the double spacing is
256 and both ids collapse to one value; 2^53+1 / 2^53+2 do NOT collapse
(2^53+2 is exactly representable), so those constants cannot pin it.
Two-arm measured: intact 18/18 pass, mutated exactly 1 fails.
- web-shell-brand.test.ts: stat the planted regular file with
`{ bigint: true }`. Production compares BigIntStats with a bare `!==`, so
the number-backed fake tripped `dev` on a type mismatch alone and would
have refused the correct file too. Probed both arms: pre-fix
`typeof expectedStat.dev === 'number'` with the `dev` clause true,
post-fix both sides bigint with `dev` false and the refusal driven by a
real inode mismatch.
- conversation-workspace.test.ts: move the `inodeVerifiable` gate below the
two `toBe(identity)` assertions. They are inode-independent, so gating
them deleted a witness the Windows lane was green on. Modelled an
unverifiable-inode host: the test reports skipped, not failed, which is
only reachable once both assertions have passed.
- worktree.test.ts: split `localFilterCommands` in two. The fail-closed
branch is platform-free by construction and the base Windows log shows it
passing there; only the `a\nb` fixture is Windows-impossible, so only that
half keeps the gate.
Co-authored-by: Qwen-Coder <[email protected]>
* ci: say why the post-redirect autocrlf line is not a duplicate
Both workflows now run `git config --global core.autocrlf false` twice: once
before the checkout and once inside the test step, where HOME/USERPROFILE are
redirected to a freshly created empty directory. The second line therefore
writes a different global config than its twin, and on ci.yml's hosted
windows-2022 fallback the pre-checkout step never runs at all because it is
gated on `runner.environment == 'self-hosted'`.
It was the only one of the three occurrences with no comment, so deduping it
looks free and silently returns CRLF conversion to every git operation the
suites perform. Replaying no-ak-integration-ci.test.js's own assertions with
the second occurrence deleted gives identical indices and still passes, so no
test notices the removal.
Comments only. The ordering assertions search for the FIRST occurrence and
none of the added text matches a needle they look for; the 14 assertions in
no-ak-integration-ci.test.js still pass.
Co-authored-by: Qwen-Coder <[email protected]>
---------
Co-authored-by: Qwen-Coder <[email protected]>