morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #2212] [MERGED] fix(adb): count UTF-8 bytes in logcat total_bytes #5087

New issue

Closed

opened 2026-10-31 01:03:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:03:45 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2212
Author: @sx4im
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/12/2026
Merged by: @morluto

Base: main ← Head: fix/adb-logcat-total-bytes-utf8

📝 Commits (2)

5c30d44 fix(adb): count UTF-8 bytes in logcat total_bytes
50fc35d fix(adb): count raw captured bytes in logcat total_bytes

📊 Changes

2 files changed (+45 additions, -2 deletions)

View changed files

📝 src/adb/AdbProvider.test.ts (+38 -0)
📝 src/adb/AdbProvider.ts (+7 -2)

📄 Description

Summary

Fixes #2175. read_adb_logcat reported total_bytes in UTF-16 code units instead of bytes. Any dump with CJK or emoji undercounted: a 37-byte CJK line came back as 33.

Problem and expected behavior

AdbProvider decodes the captured stdout buffer as UTF-8, then assigns the resulting string's .length to total_bytes. .length counts UTF-16 code units, so multi-byte characters shrink the number. The field is named total_bytes, so it should be a byte count. ASCII output was unaffected.

Change and scope

One line in src/adb/AdbProvider.ts:

total_bytes: Buffer.byteLength(ran.value.stdout, "utf8"),

Buffer.byteLength is already the codebase convention for this. I grepped every producer of this field: this is the only place read_adb_logcat's total_bytes is computed, so no sibling call sites needed the same fix. An alternative was threading the raw capture buffer through runAdb instead of re-encoding the decoded string; for valid UTF-8 the re-encoded count equals the captured byte count, so the extra plumbing buys nothing.

Contract and boundary impact

Semantic owner and earliest changed stage: AdbProvider read_adb_logcat result projection; no schema change, the field stays a nonnegative int.
CLI and MCP/tool-catalog contract: none, same schema, corrected value.
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: total_bytes now matches the captured byte count; message text, line splitting, and coverage are untouched.
Process execution, authorization, cleanup, or containment impact: none.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Evidence and regression coverage

Tests added or updated: src/adb/AdbProvider.test.ts gains "reports UTF-8 byte counts in total_bytes for non-ASCII logcat output". A stub adb emits one CJK and one emoji log line; the test asserts the decoded lines are intact and total_bytes is 72 (37 + 35).
Base reproduction or other evidence: the new test fails on the pre-fix revision, reporting 66 (the UTF-16 unit count), and passes after the fix.
User-visible CLI/MCP output (if applicable): total_bytes in the read-adb-logcat result changes for non-ASCII dumps; ASCII dumps are byte-identical.
Remaining proof gaps: reproduction used a synthetic adb stub; no real device was available. The issue itself notes this gap.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

npx vitest run src/adb/ — 4 files, 98 tests, all pass (new test failed pre-fix: expected 72, got 66)
npm run check:fast — typecheck + lint, 2 tasks successful
npx tsc --noEmit — clean

Compatibility, safety, and release

Breaking changes or migration steps: none. This corrects a value to match the field's byte unit; non-ASCII dumps will report larger (correct) numbers.
Real Hopper/Ghidra, browser, or OS coverage: not applicable; ADB provider only, synthetic stub, no real device.
Package or release metadata impact: none.
Security, privacy, process, or containment review: none; no new process execution or data capture.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 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/2212 **Author:** [@sx4im](https://github.com/sx4im) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/12/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/adb-logcat-total-bytes-utf8` --- ### 📝 Commits (2) - [`5c30d44`](https://github.com/morluto/rea/commit/5c30d442730d460378693fb70ca2f38e7b2dd953) fix(adb): count UTF-8 bytes in logcat total_bytes - [`50fc35d`](https://github.com/morluto/rea/commit/50fc35d719a8c25f2a6b3c09cc3a72de22ee73bb) fix(adb): count raw captured bytes in logcat total_bytes ### 📊 Changes **2 files changed** (+45 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/adb/AdbProvider.test.ts` (+38 -0) 📝 `src/adb/AdbProvider.ts` (+7 -2) </details> ### 📄 Description ## Summary Fixes #2175. `read_adb_logcat` reported `total_bytes` in UTF-16 code units instead of bytes. Any dump with CJK or emoji undercounted: a 37-byte CJK line came back as 33. ## Problem and expected behavior `AdbProvider` decodes the captured stdout buffer as UTF-8, then assigns the resulting string's `.length` to `total_bytes`. `.length` counts UTF-16 code units, so multi-byte characters shrink the number. The field is named `total_bytes`, so it should be a byte count. ASCII output was unaffected. ## Change and scope One line in `src/adb/AdbProvider.ts`: ```ts total_bytes: Buffer.byteLength(ran.value.stdout, "utf8"), ``` `Buffer.byteLength` is already the codebase convention for this. I grepped every producer of this field: this is the only place `read_adb_logcat`'s `total_bytes` is computed, so no sibling call sites needed the same fix. An alternative was threading the raw capture buffer through `runAdb` instead of re-encoding the decoded string; for valid UTF-8 the re-encoded count equals the captured byte count, so the extra plumbing buys nothing. ## Contract and boundary impact - Semantic owner and earliest changed stage: `AdbProvider` `read_adb_logcat` result projection; no schema change, the field stays a nonnegative int. - CLI and MCP/tool-catalog contract: none, same schema, corrected value. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: `total_bytes` now matches the captured byte count; message text, line splitting, and coverage are untouched. - Process execution, authorization, cleanup, or containment impact: none. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. ## Evidence and regression coverage - Tests added or updated: `src/adb/AdbProvider.test.ts` gains "reports UTF-8 byte counts in total_bytes for non-ASCII logcat output". A stub adb emits one CJK and one emoji log line; the test asserts the decoded lines are intact and `total_bytes` is 72 (37 + 35). - Base reproduction or other evidence: the new test fails on the pre-fix revision, reporting 66 (the UTF-16 unit count), and passes after the fix. - User-visible CLI/MCP output (if applicable): `total_bytes` in the `read-adb-logcat` result changes for non-ASCII dumps; ASCII dumps are byte-identical. - Remaining proof gaps: reproduction used a synthetic adb stub; no real device was available. The issue itself notes this gap. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npx vitest run src/adb/` — 4 files, 98 tests, all pass (new test failed pre-fix: expected 72, got 66) - `npm run check:fast` — typecheck + lint, 2 tasks successful - `npx tsc --noEmit` — clean ## Compatibility, safety, and release - Breaking changes or migration steps: none. This corrects a value to match the field's byte unit; non-ASCII dumps will report larger (correct) numbers. - Real Hopper/Ghidra, browser, or OS coverage: not applicable; ADB provider only, synthetic stub, no real device. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; no new process execution or data capture. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:03:45 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:43:21 +00:00

[PR #5239] [CLOSED] fix(evm): clarify worker address space as profile ceiling in limitations #6831

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#5087

No description provided.

Rows
Columns