[PR #2703] [CLOSED] test(ida): align the multi-slice thinning fixture to its declared slices #5326

New issue

Closed

opened 2026-10-31 01:05:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:05:46 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2703
Author: @kaoru0822-kitauji
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: test/ida-thinning-aligned-slices

📝 Commits (1)

72b0206 test(ida): align the multi-slice thinning fixture to its declared slices

📊 Changes

1 file changed (+5 additions, -3 deletions)

View changed files

📝 src/ida/IdaWorkspaceThinning.test.ts (+5 -3)

📄 Description

Problem

src/ida/IdaWorkspaceThinning.test.ts > copies exactly the selected slice when later slices follow it across read boundaries (from #2291) fails on main. That is one of the two red checks on every current PR, together with jscpd, which #2691 addresses.

Error: Cannot open artifact: FAT architecture 0 offset is not aligned to 2^14
 ❯ parseBinaryTarget src/application/BinaryTargetResolver.ts:192:11
 ❯ largeUniversalTarget src/ida/IdaWorkspaceThinning.test.ts:70:20

The fixture writes three FAT slices that each declare align = 14, but puts the first at offset 4096. Universal target resolution validates physical slice alignment (src/domain/apple/machoContainer.ts), so the fixture is rejected before IDA thinning runs. The product check is correct: a real FAT container can't place a slice there.

Fix

Only test data changes. The slices move to 16384, 32768 and 81920. The selected arm64 slice (32768–66232) still crosses the 64 KiB read boundary and is still followed by another slice, so the test still checks that no trailing bytes reach the private IDA input.

Validation

On current origin/main, npm run test:local -- src/ida/IdaWorkspaceThinning.test.ts gives 7 passed (was 1 failed, 6 passed).
format:check and check:fast pass.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2703 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `test/ida-thinning-aligned-slices` --- ### 📝 Commits (1) - [`72b0206`](https://github.com/morluto/rea/commit/72b02068583c640e60d45791aba5001095b64e46) test(ida): align the multi-slice thinning fixture to its declared slices ### 📊 Changes **1 file changed** (+5 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `src/ida/IdaWorkspaceThinning.test.ts` (+5 -3) </details> ### 📄 Description ## Problem `src/ida/IdaWorkspaceThinning.test.ts > copies exactly the selected slice when later slices follow it across read boundaries` (from #2291) fails on main. That is one of the two red checks on every current PR, together with jscpd, which #2691 addresses. ``` Error: Cannot open artifact: FAT architecture 0 offset is not aligned to 2^14 ❯ parseBinaryTarget src/application/BinaryTargetResolver.ts:192:11 ❯ largeUniversalTarget src/ida/IdaWorkspaceThinning.test.ts:70:20 ``` The fixture writes three FAT slices that each declare `align = 14`, but puts the first at offset 4096. Universal target resolution validates physical slice alignment (`src/domain/apple/machoContainer.ts`), so the fixture is rejected before IDA thinning runs. The product check is correct: a real FAT container can't place a slice there. ## Fix Only test data changes. The slices move to 16384, 32768 and 81920. The selected arm64 slice (32768–66232) still crosses the 64 KiB read boundary and is still followed by another slice, so the test still checks that no trailing bytes reach the private IDA input. ## Validation - On current `origin/main`, `npm run test:local -- src/ida/IdaWorkspaceThinning.test.ts` gives 7 passed (was 1 failed, 6 passed). - `format:check` and `check:fast` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:05:46 +00:00