Skip to content

Fix behavioural change introduced in v1 API with input validation in Email senders#1048

Merged
AfraHussaindeen merged 4 commits intowso2:masterfrom
AfraHussaindeen:master_email-sender-v1
Feb 16, 2026
Merged

Fix behavioural change introduced in v1 API with input validation in Email senders#1048
AfraHussaindeen merged 4 commits intowso2:masterfrom
AfraHussaindeen:master_email-sender-v1

Conversation

@AfraHussaindeen
Copy link
Copy Markdown
Contributor

@AfraHussaindeen AfraHussaindeen commented Jan 3, 2026

Purpose

  • $Subject

To be merged after

Public Issue

Summary by CodeRabbit

  • Internal Improvements
    • Adjusted email notification sender behavior to make activation explicit when adding or updating senders, ensuring consistent enable/disable handling.
  • Chores
    • Updated event-handler dependency to a newer version for improved stability and compatibility.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jan 3, 2026

No actionable comments were generated in the recent review. 🎉


Walkthrough

Internal calls in the notification sender API layers now forward an extra boolean flag to underlying service methods: v1 forwards true, v2 forwards false. The identity.event.handler.version property in pom.xml was bumped from 1.9.75 to 1.10.1.

Changes

Cohort / File(s) Summary
Notification Sender v1
components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v1/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v1/core/NotificationSenderManagementService.java
Internal calls changed to addEmailSender(dto, true) and updateEmailSender(dto, true). Underlying service method signatures updated to accept a boolean parameter.
Notification Sender v2
components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java
Internal calls changed to addEmailSender(dto, false) and updateEmailSender(dto, false). Invocations now use the overload that accepts a boolean parameter.
Build / Dependency
pom.xml
Updated identity.event.handler.version property from 1.9.75 to 1.10.1.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

I hop through lines with whiskers bright,
A boolean tune — true and false in flight.
V1 nods yes, V2 politely no,
Mailers ready, engines low,
Little rabbit sings: deploy with delight! 🐇📬

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description is largely incomplete. It lacks crucial sections including Goals, Approach, User stories, Developer Checklist, Release notes, Documentation, Security checks, and Test environment details required by the template. Complete all mandatory template sections: add Goals explaining how the fix resolves the issue, Approach describing implementation details, Developer Checklist confirmation, Release notes, Documentation links, and comprehensive Test environment specifications.
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title directly addresses the main change: fixing a behavioral issue in the v1 API related to email sender input validation, which aligns with the code changes passing additional boolean parameters.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Merge Conflict Detection ✅ Passed ✅ No merge conflicts detected when merging into master

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

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


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

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

Comment on lines 236 to +239

EmailSenderDTO dto = buildEmailSenderDTO(senderName, emailSenderUpdateRequest);
try {
EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto);
EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto, true);
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Log Improvement Suggestion No: 2

Suggested change
EmailSenderDTO dto = buildEmailSenderDTO(senderName, emailSenderUpdateRequest);
try {
EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto);
EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto, true);
public EmailSender updateEmailSender(String senderName, EmailSenderUpdateRequest emailSenderUpdateRequest) {
EmailSenderDTO dto = buildEmailSenderDTO(senderName, emailSenderUpdateRequest);
log.info("Updating email sender: " + senderName);
try {
EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto, true);

Copy link
Copy Markdown

@wso2-engineering wso2-engineering Bot left a comment

Choose a reason for hiding this comment

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

AI Agent Log Improvement Checklist

⚠️ Warning: AI-Generated Review Comments

  • The log-related comments and suggestions in this review were generated by an AI tool to assist with identifying potential improvements. Purpose of reviewing the code for log improvements is to improve the troubleshooting capabilities of our products.
  • Please make sure to manually review and validate all suggestions before applying any changes. Not every code suggestion would make sense or add value to our purpose. Therefore, you have the freedom to decide which of the suggestions are helpful.

✅ Before merging this pull request:

  • Review all AI-generated comments for accuracy and relevance.
  • Complete and verify the table below. We need your feedback to measure the accuracy of these suggestions and the value they add. If you are rejecting a certain code suggestion, please mention the reason briefly in the suggestion for us to capture it.
Comment Accepted (Y/N) Reason
#### Log Improvement Suggestion No: 1
#### Log Improvement Suggestion No: 2
#### Log Improvement Suggestion No: 3
#### Log Improvement Suggestion No: 4

Copy link
Copy Markdown
Contributor

@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

🧹 Nitpick comments (1)
components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java (1)

247-256: LGTM - Consistent with addEmailSender changes.

The update method correctly mirrors the pattern established in addEmailSender by passing false to maintain v2 backward compatibility.

💡 Optional: Add inline documentation for the boolean parameter

Consider adding a brief comment explaining the boolean parameter's purpose for future maintainability:

 public EmailSender updateEmailSender(String senderName, EmailSenderUpdateRequest emailSenderUpdateRequest) {

     EmailSenderDTO dto = buildEmailSenderDTO(senderName, emailSenderUpdateRequest);
     try {
+        // Pass false to disable strict validation for v2 API backward compatibility
         EmailSenderDTO emailSenderDTO = notificationSenderManagementService.updateEmailSender(dto, false);
         return buildEmailSenderFromDTO(emailSenderDTO);
     } catch (NotificationSenderManagementException e) {

Similarly for addEmailSender at line 89.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f12eae5 and 7c99975.

📒 Files selected for processing (2)
  • components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v1/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v1/core/NotificationSenderManagementService.java
  • components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: Thisara-Welmilla
Repo: wso2/identity-api-server PR: 1032
File: components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java:384-387
Timestamp: 2025-11-06T05:02:47.521Z
Learning: In components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java, SMS sender property validation is handled by the service layer builder class (SMSSenderDTO.Builder), not at the API layer, because the validation logic is complex and depends on other attributes of the object.
📚 Learning: 2025-11-06T05:02:47.521Z
Learnt from: Thisara-Welmilla
Repo: wso2/identity-api-server PR: 1032
File: components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java:384-387
Timestamp: 2025-11-06T05:02:47.521Z
Learning: In components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java, SMS sender property validation is handled by the service layer builder class (SMSSenderDTO.Builder), not at the API layer, because the validation logic is complex and depends on other attributes of the object.

Applied to files:

  • components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java
  • components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v1/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v1/core/NotificationSenderManagementService.java
🔇 Additional comments (3)
components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v2/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v2/core/NotificationSenderManagementService.java (1)

85-94: Confirmed: The boolean parameter correctly controls validation behavior.

The change from true (v1) to false (v2) for the addEmailSender and updateEmailSender method calls is correct. The boolean parameter is part of the external NotificationSenderManagementService (from org.wso2.carbon.identity.event.handler.notification framework), where:

  • true enables input validation (v1 behavior)
  • false disables validation to preserve backward compatibility (v2 behavior)

This aligns with the PR objective to fix the behavioral difference between v1 and v2 APIs, with v2 maintaining its original less-strict validation while v1 adopts stricter validation.

components/org.wso2.carbon.identity.api.server.notification.sender/org.wso2.carbon.identity.api.server.notification.sender.v1/src/main/java/org/wso2/carbon/identity/api/server/notification/sender/v1/core/NotificationSenderManagementService.java (2)

235-244: LGTM! Consistent API versioning strategy across v1 and v2.

The updateEmailSender method correctly passes true to enable input validation, matching the addEmailSender behavior. This v1 approach is intentionally differentiated from v2, which disables validation by passing false to both operations—a deliberate versioning strategy.


73-82: LGTM! The service layer method signature supports this boolean parameter.

The addition of the true parameter to enable input validation in the v1 API aligns with the PR objective to fix the behavioral change. The v1 implementation consistently passes true for both add and update operations, while v2 passes false, confirming intentional API versioning. The public method signatures remain unchanged, maintaining backward compatibility.

SujanSanjula96
SujanSanjula96 previously approved these changes Jan 9, 2026
@jenkins-is-staging
Copy link
Copy Markdown

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/22051180207

@jenkins-is-staging
Copy link
Copy Markdown

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/22051180207
Status: failure

@jenkins-is-staging
Copy link
Copy Markdown

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/22067560832

@jenkins-is-staging
Copy link
Copy Markdown

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/22067560832
Status: success

Copy link
Copy Markdown

@jenkins-is-staging jenkins-is-staging left a comment

Choose a reason for hiding this comment

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

Approving the pull request based on the successful pr build https://github.com/wso2/product-is/actions/runs/22067560832

@AfraHussaindeen AfraHussaindeen merged commit c6611b7 into wso2:master Feb 16, 2026
3 checks passed
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.

4 participants