Skip to content

[client] add support for data messages#26

Merged
capcom6 merged 1 commit intomasterfrom
features/data-messages
Jul 1, 2025
Merged

[client] add support for data messages#26
capcom6 merged 1 commit intomasterfrom
features/data-messages

Conversation

@capcom6
Copy link
Copy Markdown
Member

@capcom6 capcom6 commented Jun 28, 2025

Summary by CodeRabbit

  • New Features

    • Added support for two new message formats: plain text and base64-encoded data with a port number.
    • Introduced a new webhook event for receiving SMS data.
  • Bug Fixes

    • Improved validation to ensure only one message content field can be set at a time.
  • Tests

    • Expanded and enhanced test coverage for message content handling and validation logic.

@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 28, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines Coverage Δ
smsgateway/domain_messages.go 100.00% <100.00%> (ø)
smsgateway/domain_webhooks.go 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jun 28, 2025

Walkthrough

The changes introduce new message content types (TextMessage, DataMessage) to the message domain, update validation logic to enforce mutual exclusivity among message fields, and add corresponding tests for these behaviors. A new webhook event type is added, and test logic for the client and message validation is expanded and updated to reflect the new structures and validation rules.

Changes

File(s) Change Summary
smsgateway/domain_messages.go Added TextMessage and DataMessage types; updated Message struct to include these as optional fields; deprecated Message string field; added getters and revised Validate() to enforce exactly one message content field.
smsgateway/domain_messages_test.go Added tests for new getter methods; expanded and updated validation tests to cover new message types, mutual exclusivity, and edge cases.
smsgateway/domain_webhooks.go Added new webhook event type WebhookEventSmsDataReceived and updated event type registry.
smsgateway/client_test.go Modified test server logic to change condition for triggering a 400 Bad Request response in message sending tests.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Message
    participant Validator

    Client->>Message: Create Message (with one of Message, TextMessage, DataMessage)
    Client->>Validator: Validate(Message)
    alt Only one message field set
        Validator-->>Client: Validation Success
    else None or multiple fields set
        Validator-->>Client: Validation Error
    end
Loading
sequenceDiagram
    participant System
    participant WebhookHandler

    System->>WebhookHandler: Emit WebhookEventSmsDataReceived
    WebhookHandler-->>System: Handle event as valid type
Loading

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (1.64.8)

Error: you are using a configuration file for golangci-lint v2 with golangci-lint v1: please use golangci-lint v2
Failed executing command with error: you are using a configuration file for golangci-lint v2 with golangci-lint v1: please use golangci-lint v2


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 93e93f1 and 6a0c4d8.

📒 Files selected for processing (4)
  • smsgateway/client_test.go (1 hunks)
  • smsgateway/domain_messages.go (2 hunks)
  • smsgateway/domain_messages_test.go (1 hunks)
  • smsgateway/domain_webhooks.go (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • smsgateway/domain_webhooks.go
  • smsgateway/client_test.go
🧰 Additional context used
🧬 Code Graph Analysis (2)
smsgateway/domain_messages_test.go (3)
smsgateway/domain_messages.go (3)
  • Message (54-82)
  • TextMessage (40-43)
  • DataMessage (46-51)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
smsgateway/domain_messages.go (2)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: Analyze (actions)
  • GitHub Check: Analyze (go)
🔇 Additional comments (7)
smsgateway/domain_messages.go (3)

39-51: LGTM! New message types are well-structured.

The TextMessage and DataMessage types are properly defined with appropriate validation tags. The base64 example in DataMessage.Data correctly shows encoded content instead of plain text.


57-64: Good backward compatibility approach.

The deprecation of the Message field while adding new structured types maintains backward compatibility while providing a clear migration path.


84-104: Excellent backward compatibility implementation.

The getter methods handle the transition elegantly - GetTextMessage() falls back to the deprecated Message field when the new TextMessage field isn't set, ensuring existing code continues to work.

smsgateway/domain_messages_test.go (4)

11-66: Comprehensive test coverage for GetTextMessage().

The tests properly cover all scenarios: explicit TextMessage field, fallback to deprecated Message field, and nil return when neither is set. The backward compatibility testing is particularly valuable.


68-117: Good test coverage for GetDataMessage().

The tests appropriately cover both scenarios where DataMessage is set and when it's not set. The base64 data example is correctly encoded.


126-242: Excellent validation test coverage.

The test cases thoroughly cover all valid scenarios (exactly one field set) and invalid scenarios (none or multiple fields set). The edge case testing with empty strings is particularly important for validation behavior.


243-278: Well-structured TTL/ValidUntil validation tests.

The tests properly ensure that TTL and ValidUntil validation is only checked when valid message content is present, which aligns with the validation logic structure.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate Unit Tests
  • Create PR with Unit Tests
  • Post Copyable Unit Tests in Comment
  • Commit Unit Tests in branch features/data-messages

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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai auto-generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9fb8816 and dec5628.

📒 Files selected for processing (4)
  • smsgateway/client_test.go (1 hunks)
  • smsgateway/domain_messages.go (2 hunks)
  • smsgateway/domain_messages_test.go (1 hunks)
  • smsgateway/domain_webhooks.go (2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
smsgateway/domain_messages_test.go (3)
smsgateway/domain_messages.go (3)
  • Message (54-82)
  • TextMessage (40-43)
  • DataMessage (46-51)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
smsgateway/domain_messages.go (2)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: Test
  • GitHub Check: Lint
🔇 Additional comments (4)
smsgateway/domain_webhooks.go (1)

13-14: LGTM! Webhook event type correctly added.

The new WebhookEventSmsDataReceived event type is properly integrated following the existing pattern:

  • Declared as a constant with appropriate documentation
  • Added to the validation map
  • Included in the list of available event types

Also applies to: 28-28, 39-39

smsgateway/client_test.go (1)

29-29: Test validation correctly updated for new message structure.

The change from checking for empty message to checking for null phoneNumbers aligns with the refactored message validation logic where phoneNumbers is required but message content can be provided through multiple optional fields.

smsgateway/domain_messages_test.go (1)

11-117: Excellent test coverage for new message types!

The test suite comprehensively covers:

  • Getter methods for both message types with backward compatibility
  • Validation of mutual exclusivity between message fields
  • Edge cases with empty content
  • All possible combinations of message field settings

Also applies to: 121-299

smsgateway/domain_messages.go (1)

84-104: Well-designed backward compatibility!

The getter methods provide a clean API:

  • GetTextMessage() elegantly handles both the new field and deprecated field
  • GetDataMessage() is appropriately simple
  • This design allows smooth migration from the deprecated field

Comment thread smsgateway/domain_messages_test.go
Comment thread smsgateway/domain_messages.go
Comment thread smsgateway/domain_messages.go Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
smsgateway/domain_messages.go (1)

122-122: Error messages still exclude the deprecated field.

The validation error messages still don't mention the deprecated message field, which could confuse users who are still using it. This was identified in a previous review but hasn't been addressed.

Apply this diff to make the error messages more accurate:

-		return fmt.Errorf("%w: must specify exactly one of: textMessage or dataMessage", ErrValidationFailed)
+		return fmt.Errorf("%w: must specify exactly one of: message, textMessage, or dataMessage", ErrValidationFailed)
-		return fmt.Errorf("%w: must specify exactly one of: textMessage or dataMessage", ErrConflictFields)
+		return fmt.Errorf("%w: must specify exactly one of: message, textMessage, or dataMessage", ErrConflictFields)

Also applies to: 125-125

🧹 Nitpick comments (1)
smsgateway/domain_messages_test.go (1)

228-230: Clarify validation behavior for empty struct fields.

The comments state that empty text/data is valid because "validation is only for field presence". However, this might be misleading since the actual field validation (like required,base64) would occur at a different layer (likely through struct tags). Consider clarifying that this test only covers the message type presence validation, not the inner field validation.

Consider updating the comments to be more precise:

-			err: nil, // Empty text is valid, validation is only for field presence
+			err: nil, // Empty text passes presence check; field validation occurs separately
-			err: nil, // Empty data is valid, validation is only for field presence  
+			err: nil, // Empty data passes presence check; field validation occurs separately

Also applies to: 239-241

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dec5628 and 93e93f1.

📒 Files selected for processing (2)
  • smsgateway/domain_messages.go (2 hunks)
  • smsgateway/domain_messages_test.go (1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
smsgateway/domain_messages_test.go (3)
smsgateway/domain_messages.go (3)
  • Message (54-82)
  • TextMessage (40-43)
  • DataMessage (46-51)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
smsgateway/domain_messages.go (2)
ca/errors.go (1)
  • ErrValidationFailed (6-6)
smsgateway/types.go (2)
  • ErrValidationFailed (6-6)
  • ErrConflictFields (7-7)
🔇 Additional comments (7)
smsgateway/domain_messages.go (3)

48-48: Base64 example is now correct.

The base64 example has been fixed from the invalid "Hello World!" to the proper base64 encoding "SGVsbG8gV29ybGQh".


84-99: Well-implemented backward compatibility.

The GetTextMessage() method elegantly handles backward compatibility by constructing a TextMessage from the deprecated Message field when needed. The logic correctly prioritizes the explicit TextMessage field over the deprecated field.


101-104: Simple and correct getter implementation.

The GetDataMessage() method is straightforward and correctly returns the DataMessage pointer.

smsgateway/domain_messages_test.go (4)

11-66: Comprehensive test coverage for GetTextMessage().

The test cases thoroughly cover all scenarios: explicit TextMessage field, backward compatibility with deprecated Message field, and the case where neither is set. The test logic correctly validates both nil and non-nil return values.


68-117: Good test coverage for GetDataMessage().

The test cases properly cover both the presence and absence of the DataMessage field. The test logic correctly validates the returned pointer and its field values.


219-219: Comment has been corrected.

The comment on line 219 has been updated to accurately reflect that "Empty string is treated as field not set" instead of the previous misleading comment. This addresses the past review feedback.


125-242: Excellent validation test coverage.

The expanded test cases comprehensively cover all validation scenarios:

  • Valid cases with each individual message type
  • Invalid cases with no message fields set
  • Invalid cases with multiple message fields set (all combinations)
  • Edge cases with empty values

The test expectations correctly match the validation logic implementation.

@capcom6 capcom6 force-pushed the features/data-messages branch from 93e93f1 to 6a0c4d8 Compare June 29, 2025 11:45
@capcom6 capcom6 marked this pull request as ready for review July 1, 2025 07:04
@capcom6 capcom6 merged commit 4e5225f into master Jul 1, 2025
7 checks passed
@capcom6 capcom6 deleted the features/data-messages branch July 1, 2025 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant