fix: validate Duration in marshalDuration; add unit tests #25256
Conversation
Marcofann
changed the title
📝 WalkthroughWalkthroughAdds stricter validation logic in aminojson marshalDuration for protobuf Duration semantics and introduces unit tests covering valid, range, sign, and overflow/underflow scenarios. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant C as Caller
participant M as marshalDuration
participant P as protobuf.Duration
participant W as Writer/Encoder
C->>M: marshalDuration(ctx, P.ProtoReflect(), W)
M->>P: Read seconds, nanos
alt missing fields
M-->>C: error (missing seconds/nanos)
else validate ranges
alt seconds overflow/underflow
M-->>C: error (seconds out of range)
else nanos not in [-999999999, 999999999]
M-->>C: error (nanos out of range)
else sign mismatch (sec vs nanos)
M-->>C: error (sign mismatch)
else
M->>M: totalNanos = sec*1e9 + nanos
M->>W: write totalNanos as JSON string
M-->>C: nil
end
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
x/tx/signing/aminojson/time.go (1)
75-83: Nanos range and sign checks are correct; consider minor robustness/readability tweaksThe validations enforce protobuf Duration semantics well. Two small improvements:
- Use typed int64 constants to avoid any ambiguity with untyped 1e9 and make intent clearer.
- Include the offending values in the sign-mismatch error and clarify the “either may be zero” exception.
Apply this diff within the changed lines:
- // validate nanos range according to protobuf Duration constraints - if nanos <= -1e9 || nanos >= 1e9 { - return fmt.Errorf("nanos must be in range [-999999999, 999999999], got %d", nanos) - } + // validate nanos range according to protobuf Duration constraints + if nanos <= -int64(1_000_000_000) || nanos >= int64(1_000_000_000) { + return fmt.Errorf("nanos must be in range [-999999999, 999999999], got %d", nanos) + } - // seconds and nanos must have consistent signs - if (seconds > 0 && nanos < 0) || (seconds < 0 && nanos > 0) { - return fmt.Errorf("seconds and nanos must have the same sign") - } + // seconds and nanos must have consistent signs (or either may be zero) + if (seconds > 0 && nanos < 0) || (seconds < 0 && nanos > 0) { + return fmt.Errorf("seconds and nanos must have the same sign (or either may be zero): seconds=%d nanos=%d", seconds, nanos) + }Optional (outside the changed ranges): define named constants once for readability.
// near top of file const ( nanosPerSecond int64 = 1_000_000_000 minNanos int64 = -999_999_999 maxNanos int64 = 999_999_999 )Then use nanosPerSecond in the total computation (line 84) for clarity:
totalNanos := nanos + (seconds * nanosPerSecond)Also applies to: 84-86
x/tx/signing/aminojson/time_test.go (3)
10-26: Happy path test LGTM; tiny style nitThe assertion matches the output format and math. Style-wise, constructing the message directly is a bit clearer than creating with durationpb.New(0) and then mutating fields.
- msg := durationpb.New(0) - // 1 second and 500 nanos => 1_000_000_000 + 500 - msg.Seconds = 1 - msg.Nanos = 500 + // 1 second and 500 nanos => 1_000_000_000 + 500 + msg := &durationpb.Duration{Seconds: 1, Nanos: 500}
28-37: Range checks covered; consider asserting boundary acceptance at ±999,999,999You cover the rejection of ±1,000,000,000. Adding a positive assertion that ±999,999,999 are accepted would harden boundary coverage.
I can push a follow-up test if you’d like.
57-69: Overflow/underflow checks are correct; add max-boundary “still OK” assertionsThe tests verify we reject seconds just outside the bound. Consider adding “on the edge” positive tests to ensure seconds == MaxDurationSeconds with aligned nanos still marshal successfully.
Here are additive tests you can append (also exercises zero-seconds with signed nanos):
@@ func TestMarshalDuration_OverflowUnderflow(t *testing.T) { @@ } + +func TestMarshalDuration_BoundaryValuesAllowed(t *testing.T) { + t.Parallel() + cases := []struct{ + name string + seconds int64 + nanos int32 + }{ + {"max_seconds_zero_nanos", MaxDurationSeconds, 0}, + {"max_seconds_max_nanos", MaxDurationSeconds, 999_999_999}, + {"min_seconds_zero_nanos", -MaxDurationSeconds, 0}, + {"min_seconds_min_nanos", -MaxDurationSeconds, -999_999_999}, + {"zero_seconds_pos_nanos", 0, 999_999_999}, + {"zero_seconds_neg_nanos", 0, -999_999_999}, + } + for _, tc := range cases { + t.Run(tc.name, func(t *testing.T) { + msg := &durationpb.Duration{Seconds: tc.seconds, Nanos: tc.nanos} + var buf bytes.Buffer + if err := marshalDuration(nil, msg.ProtoReflect(), &buf); err != nil { + t.Fatalf("unexpected error for %s: %v", tc.name, err) + } + }) + } +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Knowledge Base: Disabled due to Reviews > Disable Knowledge Base setting
📒 Files selected for processing (2)
x/tx/signing/aminojson/time.go(1 hunks)x/tx/signing/aminojson/time_test.go(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (2)
x/tx/signing/aminojson/time.go (1)
61-67: Good guard against int64 overflow/underflow from seconds→nanoseconds conversionThe explicit bounds on seconds vs MaxDurationSeconds look correct and prevent overflow in the subsequent seconds*1e9 multiplication.
x/tx/signing/aminojson/time_test.go (1)
39-55: Sign-mismatch tests are precise and effectiveThe table captures both mismatch directions succinctly. No issues.
|
@Marcofann lint is failing |
|
needs a changelog as well |
Marcofann
force-pushed
the
update/tests
branch
from
e14e28a to
9207c36
Compare
|
@aljo242 Thanks for the feedback! I've fixed both issues:
|
Files:
Summary by CodeRabbit