Fix TCP_USER_TIMEOUT overflow

[yzfeng2020]

Motivation:

ChannelUtil.applyDefaultChannelOptions() overflows when idleTimeoutMillis is near Long.MAX_VALUE. The expression idleTimeoutMillis + TCP_USER_TIMEOUT_BUFFER_MILLIS (where the buffer is 5,000)
wraps the long type to a large negative number, and Ints.saturatedCast() then clamps it to Integer.MIN_VALUE (-2,147,483,648).

Linux rejects this negative value for TCP_USER_TIMEOUT via setsockopt() with EINVAL. Starting with Netty 4.1.131+, channel option values are validated at set time and throw exceptions
instead of being silently logged internally (see netty/netty#15896). This means the overflow now causes a hard failure rather than a silent misconfiguration.

Modifications:

• Use LongMath.saturatedAdd to prevent the long overflow before passing the result to Ints.saturatedCast:

  final int tcpUserTimeoutMillis =
          Ints.saturatedCast(LongMath.saturatedAdd(idleTimeoutMillis,
                                                   TCP_USER_TIMEOUT_BUFFER_MILLIS));

• Add a regression test that passes Long.MAX_VALUE as idleTimeoutMillis and asserts the result is Integer.MAX_VALUE.

Result:

• Long.MAX_VALUE idle timeout no longer overflows — produces Integer.MAX_VALUE (~24.8 day timeout) instead of Integer.MIN_VALUE (rejected by Linux).
• For normal values (e.g., 2000), Math.min is a no-op and behavior is unchanged.

[coderabbitai]

📝 Walkthrough

Walkthrough

Use overflow-safe addition when computing TCP_USER_TIMEOUT: LongMath.saturatedAdd(idleTimeoutMillis, TCP_USER_TIMEOUT_BUFFER_MILLIS) before Ints.saturatedCast; added a parameterized test asserting the TCP user timeout clamps to Integer.MAX_VALUE when maxIdleTimeout is Long.MAX_VALUE. (≤50 words)

Changes

Cohort / File(s)	Summary
TCP User Timeout Overflow Fix core/src/main/java/com/linecorp/armeria/internal/common/util/ChannelUtil.java	Replace direct idleTimeoutMillis + TCP_USER_TIMEOUT_BUFFER_MILLIS with LongMath.saturatedAdd(...) and then Ints.saturatedCast to avoid intermediate long overflow when deriving TCP_USER_TIMEOUT.
Test Coverage for Overflow Scenario core/src/test/java/com/linecorp/armeria/internal/common/util/ChannelUtilTest.java	Add parameterized test tcpUserTimeoutWithMaxIdleTimeout to verify the computed TCP user timeout is clamped to Integer.MAX_VALUE when maxIdleTimeout is Long.MAX_VALUE.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• Remove setting SO_KEEPALIVE related options by default #6648 — Modified ChannelUtil.applyDefaultChannelOptions and TCP_USER_TIMEOUT handling; related to TCP_USER_TIMEOUT computation changes.

Suggested labels

defect

Suggested reviewers

• trustin
• ikhoon
• minwoox

Poem

🐰 I nudged the sums with gentle care,
So longs won't tumble unaware.
A buffered hop,
No overflow flop,
Now TCP naps safe in my lair 🥕🛠️

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely identifies the primary fix: preventing TCP_USER_TIMEOUT overflow in ChannelUtil, which is the main change in the changeset.
Description check	✅ Passed	The pull request description clearly explains the overflow bug in TCP_USER_TIMEOUT calculation, the root cause, the fix using LongMath.saturatedAdd, and the expected behavior improvement.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[github-actions]

🔍 Build Scan® (commit: 366089d)

Job name	Status	Build Scan®
build-ubicloud-standard-16-jdk-8	✅	https://ge.armeria.dev/s/3cduswlrk5bim
build-ubicloud-standard-16-jdk-25	✅	https://ge.armeria.dev/s/4ex3cx47bf3c4
build-ubicloud-standard-16-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/qnuuet6p3re3u
build-ubicloud-standard-16-jdk-17-min-java-17-coverage	❌ (failure)	https://ge.armeria.dev/s/njsffoifkhgbc
build-ubicloud-standard-16-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/p36rarerclgfu
build-ubicloud-standard-16-jdk-17-leak	✅	https://ge.armeria.dev/s/njar3bafxuaxu
build-ubicloud-standard-16-jdk-11	✅	https://ge.armeria.dev/s/lztbbsk5o2zdi
build-macos-latest-jdk-25	✅	https://ge.armeria.dev/s/n2z3o6vugxvki

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.00%. Comparing base (8150425) to head (94aae8d).
⚠️ Report is 408 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6711      +/-   ##
============================================
- Coverage     74.46%   74.00%   -0.46%     
- Complexity    22234    24118    +1884     
============================================
  Files          1963     2176     +213     
  Lines         82437    90501    +8064     
  Branches      10764    11859    +1095     
============================================
+ Hits          61385    66975    +5590     
- Misses        15918    17906    +1988     
- Partials       5134     5620     +486     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 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.

[jrhee17]

👍 👍

[ikhoon]

Nice catch! 🚀🚀

[minwoox]

Thanks!