feat(core): Support for multiple outgoing webhooks added #7578
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sweta-Kumari-Sharma
added
A-core
hyperswitch-bot
bot
added
the
M-database-changes
| @@ -52,7 +52,7 @@ pub struct MerchantAccountCreate { | |||
| pub return_url: Option<url::Url>, | |||
|
|
|||
| /// Webhook related details | |||
| pub webhook_details: Option<WebhookDetails>, | |||
| pub webhook_details: Option<Vec<Option<WebhookDetails>>>, | |||
There was a problem hiding this comment.
There are two options here, which seem redundant. Is there any specific reason to do so?
| ///The password for Webhook login | ||
| #[schema(value_type = Option<String>, max_length = 255, example = "ekart@123")] | ||
| pub webhook_password: Option<Secret<String>>, | ||
| pub webhook_endpoint_id: Option<id_type::WebhookEndpointId>, |
There was a problem hiding this comment.
is this change backwards compatible?
| @@ -239,6 +239,13 @@ pub fn generate_profile_id_of_default_length() -> id_type::ProfileId { | |||
| id_type::ProfileId::generate() | |||
| } | |||
|
|
|||
| /// Generate a profile id with default length, with prefix as `pro` | |||
There was a problem hiding this comment.
Please change the doc comment
| #[serde(rename_all = "snake_case")] | ||
| #[strum(serialize_all = "snake_case")] | ||
| pub enum OutgoingWebhookEndpointStatus { | ||
| Active, |
There was a problem hiding this comment.
please provide description to these enums. What is the difference between inactive and deprecated? if once made as deprecated, it cannot be made active?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of Change
Description
In the current system, merchants can configure only one webhook endpoint per profile. This PR introduces support for configuring multiple webhook endpoints based on the event_type. These changes include modifications to the database schema and alterations in the webhook triggering logic.
Database Schema Changes
The webhook_details column in the business_profile table is being updated from a JSON object to an array of JSON objects. This will allow each business profile to store multiple webhook endpoints that can be associated with different event types.
Old Schema (Single webhook configuration):
{
"webhook_url": "https://example.com/webhook",
"events": ["payment_succeeded"]
}
New Schema (Multiple webhook configurations):
[
{
"webhook_url": "https://example1.com/webhook",
"events": ["payment_succeeded", "order_created"]
},
{
"webhook_url": "https://example2.com/webhook",
"events": ["payment_failed"]
}
]
2. Merchant Account Schema Update:
The merchant_account table might also include the webhook_details field to store webhook configurations for the merchant, allowing the use of multiple endpoints for different events.
The database migrations will need to reflect these changes to handle an array of webhook configurations instead of a single configuration.
Event Handling Logic
Triggering the First Webhook: When an event (e.g., a payment) occurs, the first webhook endpoint is triggered. This is determined by matching the event_type against the webhook configurations stored in the business_profile. The first matching webhook endpoint is used to trigger the webhook request.
Process Tracker for Remaining Webhooks: For the remaining webhook endpoints, even though they won't be triggered immediately, the system will log these events in the process tracker for future attempts. This is useful for retrying failed webhook calls or ensuring that the webhooks are eventually delivered.
Webhook Retry Handling: Each webhook delivery attempt, whether initial or retry, will be recorded in the process_tracker. This ensures that failed webhook deliveries are retried.
Additional Changes
Motivation and Context
How did you test it?
Response
Response
Checklist
cargo +nightly fmt --allcargo clippy