morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #5121] [Bug] Main CI red since `3537e58c1`: three test files expect old plist shapes #3153

New issue

Closed

opened 2026-10-31 00:37:15 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:37:15 +00:00

Owner

Originally created by @CassieFox23 on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5121

TL;DR: Main CI has been red since 3537e58c1. That commit changed plist output on purpose. Three test files still expect the old output. The fix is test-only. I have one ready and will open a PR unless you would rather do it.

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Other

Observed behavior

Main 32f0e5120 fails CI. The first red commit is 3537e58c1. Its title is fix(plist)!: preserve unknown XML scalar identities, and it closes #4852. Its parent cee95b2ae passes.

Test file	Failing tests
`keyedArchiveNumberMetadata` (filesystem, CLI and MCP surfaces)	24 of 50
`keyedArchiveDateRange`	1 (Node 24)
`interfaceBuilderBundle`	1 (Node 24)

CI runs: 39155858235 is the first red run, on 3537e58c1. 39163665969 is red on 32f0e5120.

CI logs repeat the date-range and Interface Builder tests across jobs. Each is really one test. I ran both files on main with Node 24 only. Each had 1 failure.

The 2 nativeUiFinalizationMcp failures on main are a separate problem. gensokyo-dev already noted them on #5056.

Reproduction

Check out 32f0e5120.

Build, then run the two number-metadata files:

npm ci && npm run build:cached && npm run test:prepare
npm run test:focused -- tests/boundary/filesystem/keyedArchiveNumberMetadata.test.ts tests/boundary/mcp/keyedArchiveNumberMetadataMcp.test.ts

Result: 24 failed, 26 passed. Same on Node 22.23.1, 24.18.0 and 26.11.1 (exit 1 each).
Run the same two files on cee95b2ae. Result: 50 passed.

Expected behavior

Tests match the intended behavior of 3537e58c1. The commit changes the output on purpose. Unreadable XML scalars now become unknown values. The fixture tests/fixtures/keyedArchiveNumberMetadata.ts and the date expectations were not updated.

Impact and scope

Main CI is red for every later change. A red main hides new failures. Only tests are affected. I found no source bug (unverified beyond the test runs above). I did not check macOS plutil output.

REA version

Main at 32f0e5120. First bad 3537e58c1. Last good cee95b2ae.

Runtime and platform

Node 22.23.1, 24.18.0, 26.11.1; Nobara 44 (Fedora 44 base), Linux 7.2.9, x86_64

Target and artifact context

Not applicable. Keyed archive fixtures and XML plists built by the repo's own test helpers.

Interface

Other

Earliest failure stage

Unknown

Relevant output or evidence

Commands run: the two test files above, on three Node versions, on cee95b2ae and on main 32f0e5120. Results are in the Reproduction section. CI evidence is the two run IDs above.

The fix was checked on a tree with the fix applied. Five files ran: the number-metadata pair, keyedArchiveDateRange, interfaceBuilderBundle and keyedArchiveXmlScalars. Result: 75 passed, 24 skipped (they need ibtool), 0 failed, on Node 22, 24 and 26. The tsc, oxfmt --check and oxlint checks were clean. Parent cee95b2ae gives 74 passed on the same files.

Typed outcome or recovery expected

Not applicable.

Analysis or suspected cause

This is my reading of the source. I did not trace it end to end. 3537e58c1 changed the output, and the tests were left behind.

What the ready fix changes

The first value expects the exact integer.
The other value expects an unknown wrapper for the integer. Its reason is unsupported-markup if the literal has <, else invalid-literal.
The entity-encoded integer case expects unknown and incomplete: true.
The limitation text expects "1 XML scalar value(s) could not be established".
Year 11507 keeps its timestamp now. In the date tests, the year 11507 literal becomes year 300000. No JavaScript date can hold that. The tests expect the unknown wrapper for it.
The interfaceBuilderBundle regex now says "1 XML scalar value(s)" where it said "1 date value(s)".

The change touches tests and one test fixture. It does not touch source.

Two questions for the maintainer:

Is it intended that an entity-encoded integer such as <integer>9007199254740993</integer> is now unknown? The acceptance test in 3537e58c1 lists 42 as unknown, so I think yes.
XML dates can no longer give iso8601: null. Can the unknownDateCount branch still be reached from binary plists? I did not trace this.

Additional context

Last known good: cee95b2ae. First known bad: 3537e58c1. 3537e58c1 was pushed to main without a PR. I found no one else working on this. PRs #4054 and #4047 touch the same fixture but are old and unrelated.

I have the fix ready as a test-only change. I will open a PR for it unless you would rather do it.

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 22.23.1, 24.18.0, 26.11.1
Head / base: 32f0e5120 / cee95b2ae

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

Originally created by @CassieFox23 on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5121 **TL;DR:** Main CI has been red since 3537e58c1. That commit changed plist output on purpose. Three test files still expect the old output. The fix is test-only. I have one ready and will open a PR unless you would rather do it. ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Other ### Observed behavior Main 32f0e5120 fails CI. The first red commit is 3537e58c1. Its title is `fix(plist)!: preserve unknown XML scalar identities`, and it closes #4852. Its parent cee95b2ae passes. | Test file | Failing tests | | --- | --- | | `keyedArchiveNumberMetadata` (filesystem, CLI and MCP surfaces) | 24 of 50 | | `keyedArchiveDateRange` | 1 (Node 24) | | `interfaceBuilderBundle` | 1 (Node 24) | CI runs: 39155858235 is the first red run, on 3537e58c1. 39163665969 is red on 32f0e5120. CI logs repeat the date-range and Interface Builder tests across jobs. Each is really one test. I ran both files on main with Node 24 only. Each had 1 failure. The 2 `nativeUiFinalizationMcp` failures on main are a separate problem. gensokyo-dev already noted them on #5056. ### Reproduction 1. Check out 32f0e5120. 2. Build, then run the two number-metadata files: ```bash npm ci && npm run build:cached && npm run test:prepare npm run test:focused -- tests/boundary/filesystem/keyedArchiveNumberMetadata.test.ts tests/boundary/mcp/keyedArchiveNumberMetadataMcp.test.ts ``` 3. Result: 24 failed, 26 passed. Same on Node 22.23.1, 24.18.0 and 26.11.1 (exit 1 each). 4. Run the same two files on cee95b2ae. Result: 50 passed. ### Expected behavior Tests match the intended behavior of 3537e58c1. The commit changes the output on purpose. Unreadable XML scalars now become `unknown` values. The fixture `tests/fixtures/keyedArchiveNumberMetadata.ts` and the date expectations were not updated. ### Impact and scope Main CI is red for every later change. A red main hides new failures. Only tests are affected. I found no source bug (unverified beyond the test runs above). I did not check macOS `plutil` output. ### REA version Main at 32f0e5120. First bad 3537e58c1. Last good cee95b2ae. ### Runtime and platform Node 22.23.1, 24.18.0, 26.11.1; Nobara 44 (Fedora 44 base), Linux 7.2.9, x86_64 ### Target and artifact context Not applicable. Keyed archive fixtures and XML plists built by the repo's own test helpers. ### Interface Other ### Earliest failure stage Unknown ### Relevant output or evidence Commands run: the two test files above, on three Node versions, on cee95b2ae and on main 32f0e5120. Results are in the Reproduction section. CI evidence is the two run IDs above. The fix was checked on a tree with the fix applied. Five files ran: the number-metadata pair, `keyedArchiveDateRange`, `interfaceBuilderBundle` and `keyedArchiveXmlScalars`. Result: 75 passed, 24 skipped (they need `ibtool`), 0 failed, on Node 22, 24 and 26. The `tsc`, `oxfmt --check` and `oxlint` checks were clean. Parent cee95b2ae gives 74 passed on the same files. ### Typed outcome or recovery expected Not applicable. ### Analysis or suspected cause This is my reading of the source. I did not trace it end to end. 3537e58c1 changed the output, and the tests were left behind. <details> <summary>What the ready fix changes</summary> - The `first` value expects the exact integer. - The `other` value expects an `unknown` wrapper for the integer. Its reason is `unsupported-markup` if the literal has `<`, else `invalid-literal`. - The entity-encoded integer case expects `unknown` and `incomplete: true`. - The limitation text expects "1 XML scalar value(s) could not be established". - Year 11507 keeps its timestamp now. In the date tests, the year 11507 literal becomes year 300000. No JavaScript date can hold that. The tests expect the unknown wrapper for it. - The `interfaceBuilderBundle` regex now says "1 XML scalar value(s)" where it said "1 date value(s)". The change touches tests and one test fixture. It does not touch source. </details> Two questions for the maintainer: 1. Is it intended that an entity-encoded integer such as `<integer>9007199254740993</integer>` is now unknown? The acceptance test in 3537e58c1 lists `42` as unknown, so I think yes. 2. XML dates can no longer give `iso8601: null`. Can the `unknownDateCount` branch still be reached from binary plists? I did not trace this. ### Additional context Last known good: cee95b2ae. First known bad: 3537e58c1. 3537e58c1 was pushed to main without a PR. I found no one else working on this. PRs #4054 and #4047 touch the same fixture but are old and unrelated. I have the fix ready as a test-only change. I will open a PR for it unless you would rather do it. <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 22.23.1, 24.18.0, 26.11.1 - Head / base: 32f0e5120 / cee95b2ae </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi closed this issue

2026-10-31 00:37:15 +00:00

bsakaguchi commented

2026-10-31 00:37:16 +00:00

Author

Owner

@morluto commented on GitHub (Oct 18, 2026):

Closing as completed by d1adc6079 on main.

The shared plist fixture and date/Interface Builder expectations now follow explicit unknown XML scalar semantics. The same commit updates UI finalization regressions. Its recorded validation includes 187 source cases, 138 focused public cases and a final 97-case rerun; current full CI is separate.

This is source/history reconciliation using the existing validation record; no new local test or provider run is claimed.

@morluto commented on GitHub (Oct 18, 2026):  Closing as completed by [d1adc6079](https://github.com/morluto/rea/commit/d1adc607952472b6db87d1fe5af4ba241f759f6e) on `main`. The shared plist fixture and date/Interface Builder expectations now follow explicit unknown XML scalar semantics. The same commit updates UI finalization regressions. Its recorded validation includes 187 source cases, 138 focused public cases and a final 97-case rerun; current full CI is separate. This is source/history reconciliation using the existing validation record; no new local test or provider run is claimed.

bsakaguchi commented

2026-10-31 00:37:16 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 18, 2026):

Thanks for closing this. I also checked d1adc6079 on Linux with Node 22, 24 and 26. The three files pass now, and so does nativeUiFinalizationMcp. The commit message answers my first question too. Integer entities are not valid plist integers. So unknown is right.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 18, 2026): Thanks for closing this. I also checked d1adc6079 on Linux with Node 22, 24 and 26. The three files pass now, and so does `nativeUiFinalizationMcp`. The commit message answers my first question too. Integer entities are not valid plist integers. So `unknown` is right. 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi referenced this issue

2026-10-31 01:08:56 +00:00

[PR #3404] feat(artifacts): recognize CFB containers with explicit coverage limits #5722

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3153

No description provided.

Rows
Columns

[GH-ISSUE #5121] [Bug] Main CI red since 3537e58c1: three test files expect old plist shapes #3153

Before submitting

Area

Observed behavior

Reproduction

Expected behavior

Impact and scope

REA version

Runtime and platform

Target and artifact context

Interface

Earliest failure stage

Relevant output or evidence

Typed outcome or recovery expected

Analysis or suspected cause

Additional context

[GH-ISSUE #5121] [Bug] Main CI red since `3537e58c1`: three test files expect old plist shapes #3153