🧹 refactor: Fix signed integer reading for TON workchain in utils

[zknpr]

🎯 What: Modified projects/helper/utils/ton.js to parse the TON workchain directly via addr.readInt8(1) rather than doing a manual comparison with 0xff.
💡 Why: This satisfies a pending TODO comment in the codebase, significantly reducing code clutter and making use of standard Node.js Buffer APIs for 8-bit signed integer reading, which is safer and less verbose.
✅ Verification: A node test was performed which confirmed -1 is parsed correctly as the workchain for masterchain addresses, and syntax remains valid without any other behavioral changes.
✨ Result: Enhanced the parsing robustness and readability for ton.js utilities.

---

PR created automatically by Jules for task 1896806441474352495 started by @zknpr

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[coderabbitai]

Warning

Rate limit exceeded

@zknpr has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 20 minutes and 41 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 09e91a4e-dcb3-4a49-a43d-ba6e749afb09

📥 Commits

Reviewing files that changed from the base of the PR and between 0d3be2a and 7ba01a4.

📒 Files selected for processing (1)

• projects/helper/utils/ton.js

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-ton-signed-int-read-1896806441474352495

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR refactors the workchain byte parsing in projects/helper/utils/ton.js by replacing a manual 0xff comparison with a direct call to addr.readInt8(1), satisfying the existing TODO comment in the code. The change reduces boilerplate and delegates signed 8-bit integer interpretation to Node.js's native Buffer API.

• The new approach is semantically correct: Buffer.readInt8 reads the byte as a two's complement signed 8-bit integer, so 0xff is correctly returned as -1 (masterchain) and 0x00 as 0 (base workchain) — matching the previous behaviour for all valid TON workchain identifiers.
• The refactor also changes behaviour for byte values in the range 0x80–0xfe: the old code returned them as unsigned positive integers (128–254), while readInt8 will return them as negative signed values (-128 to -2). In practice this has no impact because TON only uses workchain IDs 0 and -1.
• addr is produced via Buffer.subarray, which returns a Buffer instance, so readInt8 is available without any casting.
• No other logic is affected.

Confidence Score: 5/5

• This PR is safe to merge — the refactor is functionally equivalent for all real-world TON workchain values and correctly fulfils the existing TODO.
• The change is a one-line simplification that uses a well-known Node.js Buffer API. Behaviour for the two valid TON workchain IDs (0 and -1) is identical to the previous code. No edge cases are introduced, tests were confirmed manually, and the rest of the file is untouched.
• No files require special attention.

Important Files Changed

Filename	Overview
projects/helper/utils/ton.js	Single-line refactor replacing a manual 0xff comparison with addr.readInt8(1) to correctly parse the workchain as a signed 8-bit integer; resolves the existing TODO and is semantically equivalent for all practical TON workchain values (0 and -1).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[parseFriendlyAddress called] --> B[Decode base64 and validate length == 36]
    B --> C[Split addr bytes 0-33 and crc bytes 34-35]
    C --> D[CRC-16 checksum verification]
    D --> E{Valid checksum?}
    E -- No --> F[Throw Invalid checksum]
    E -- Yes --> G[Parse tag byte]
    G --> H{test_flag set?}
    H -- Yes --> I[isTestOnly = true, strip flag]
    H -- No --> J[isTestOnly = false]
    I --> K{Known address tag?}
    J --> K
    K -- No --> L[Throw Unknown address tag]
    K -- Yes --> M[isBounceable = tag === bounceable_tag]
    M --> N[workchain = addr.readInt8 at offset 1]
    N --> O[hashPart = addr.subarray 2 to 34]
    O --> P[Return isTestOnly, isBounceable, workchain, hashPart]

Loading

_{Last reviewed commit: 7ba01a4}