[armnkumar321-spec]

Which issue does this PR address?

Closes #4795

Rationale

DELETE_SEGMENTS.serialize in the Node SDK had no unit test, so a change to the payload layout or to the segments count bounds would go unnoticed.

What changed?

Adds foreign/node/src/wire/segment/delete-segments.command.test.ts (node:test + node:assert/strict, same layout as create-user.command.test.ts). No production code changed.

• Numeric stream/topic identifiers: compares the full payload against bytes written out by hand. topicId: 300 encodes as 2c 01 00 00, so the test also pins little-endian order.
• String stream/topic identifiers: same check, with [2, length] followed by the name bytes.
• Segments count 1 and 1000 are accepted, and the last four bytes hold the count.
• Segments count 0 and 1001 throw. The tests only check that it throws, because the current message ("Topic partition_count must be between 1 and 1000") names the wrong field. Fixing that is a separate change.

The expected buffers are built with Buffer.concat from literal bytes and never call serializeIdentifier or uint32ToBuf. I made sure the tests fail if the partition id and segments count are swapped or the upper bound changes.

One thing to confirm, outside this PR: the SDK rejects counts above 1000, but the server's DeleteSegments::validate accepts any u32. These tests lock in the SDK's 1..=1000 range as it is today.

Local Execution

In foreign/node on macOS, Node 24.22.2:

• npm run test:unit: 971 tests passed, 0 failed. delete-segments.command.ts and segment.utils.ts now have 100% line, branch and function coverage.
• npm run lint: passed.
• npx tsc -p tsconfig.json --noEmit: passed.

[github-actions]

Thanks for the PR. It is labeled S-waiting-on-review and queued for review.

If AI assistance was used to create this PR, you are required to run the team-review skill before opening it.

Slash commands (own line, regular comment) move it around the queue:

• /ready - back to S-waiting-on-review after addressing feedback
• /author - flip to S-waiting-on-author while you finish changes
• /request-review @user-or-team - request a reviewer
• /pin - exempt the PR from the stale bot, /unpin to undo

See CONTRIBUTING.md for details.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.10%. Comparing base (c1fc441) to head (1adacb6).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #4829      +/-   ##
============================================
- Coverage     91.29%   91.10%   -0.20%     
+ Complexity     4204     3878     -326     
============================================
  Files          1458     1563     +105     
  Lines        340825   406984   +66159     
  Branches     272619   340170   +67551     
============================================
+ Hits         311170   370795   +59625     
- Misses        23439    28784    +5345     
- Partials       6216     7405    +1189     

Components	Coverage Δ
Rust Core	92.31% <ø> (-0.75%)	⬇️
Java SDK	79.37% <ø> (-1.18%)	⬇️
C# SDK	84.42% <ø> (+4.35%)	⬆️
Python SDK	86.52% <ø> (-0.11%)	⬇️
PHP SDK	92.23% <ø> (-0.03%)	⬇️
Node SDK	97.16% <ø> (+0.10%)	⬆️
Go SDK	71.66% <ø> (-1.72%)	⬇️
C++ SDK	86.84% <ø> (+0.07%)	⬆️
see 352 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[justinmclean]

Thanks @armnkumar321-spec, and welcome. You are right about the range. serializeSegmentsParams in the Node SDK rejects anything outside 1 to 1000, and its error message names partition_count, but the server's DeleteSegments::validate accepts any count. Could you open an issue for that, covering both the limit and the message? Keeping it out of this PR is fine.

[armnkumar321-spec]

Thanks for the welcome! Opened #4850 for the segments-count range and the error message.