bullet_train 1.25.1 → 1.26.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/app/views/account/users/_form.html.erb +1 -1
- data/docs/webhooks/outgoing.md +46 -2
- data/lib/bullet_train/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 4c7823b24dc2c8be4c99997d03b289b3fea611dc07abd77375557820a46b5794
|
|
4
|
+
data.tar.gz: '055490329ac98e91caa8885faf46acf7526f1aa6484318bd09c55f16bd7e0fc9'
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: e6ebeee777c71ffc32b92eb18d32e93708a4e65a00173ad90124a8e0c5ad6aec9f5a7b36e138bb15c2ca0570155b3cc7cfcdf3ed437e0b50493c28b52cc21c28
|
|
7
|
+
data.tar.gz: ce970e8958b7c49365e12b3b3a70def2ca5000fc2c836c8d523920149bf7547c70190191a0f00f14e8f7a1cac33d927823afe1fe0c53adc3047cf046e4245429
|
|
@@ -27,7 +27,7 @@
|
|
|
27
27
|
|
|
28
28
|
<% if multiple_locales? %>
|
|
29
29
|
<div class="sm:col-span-2">
|
|
30
|
-
<%= render 'shared/fields/buttons', method: :locale,
|
|
30
|
+
<%= render 'shared/fields/buttons', method: :locale, button_field_options: {"": t("locale.default")}.merge(t("locale.locales")) %>
|
|
31
31
|
</div>
|
|
32
32
|
<% end %>
|
|
33
33
|
|
data/docs/webhooks/outgoing.md
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
Webhooks allow for users to be notified via HTTP request when activity takes place on potentially any piece of data in your application. Bullet Train applications include an entire user-facing UI that allows them not only to create webhook endpoints, but also see a history of their attempted deliveries and debug delivery issues.
|
|
5
5
|
|
|
6
6
|
## Default Event Types
|
|
7
|
-
Bullet Train can deliver webhooks for any model you've added under `Team`. We call the model a webhook is being issued for the "subject".
|
|
7
|
+
Bullet Train can deliver webhooks for any model you've added under `Team`. We call the model a webhook is being issued for the "subject".
|
|
8
8
|
|
|
9
9
|
An "event type" is a subject plus an action. By default, every model includes `created`, `updated`, and `destroyed` event types. These are easy for us to implement automatically because of [Active Record Callbacks](https://guides.rubyonrails.org/active_record_callbacks.html).
|
|
10
10
|
|
|
@@ -25,11 +25,55 @@ payment.generate_webhook(:succeeded)
|
|
|
25
25
|
```
|
|
26
26
|
|
|
27
27
|
## Delivery
|
|
28
|
-
Webhooks are delivered
|
|
28
|
+
Webhooks are delivered asynchronously in a background job by default. If the resulting HTTP request results in a status code other than those in the 2XX series, it will be considered a failed attempt and delivery will be reattempted a number of times.
|
|
29
29
|
|
|
30
30
|
## Security
|
|
31
31
|
Your outgoing webhook events come with a signature that your users can verify on the receiving end. More info in the [Security section of the Incoming Webhooks docs](./incoming.md#security)
|
|
32
32
|
|
|
33
|
+
## Endpoint Deactivation
|
|
34
|
+
|
|
35
|
+
Note: This feature is disabled by default.
|
|
36
|
+
|
|
37
|
+
To prevent resource waste and improve system reliability, Bullet Train can automatically deactivate webhook endpoints that consistently fail to receive deliveries. This feature helps handle situations where an endpoint URL goes down hard and stays down for an extended period.
|
|
38
|
+
|
|
39
|
+
This automatic deactivation system ensures that resources aren't wasted on persistently failing endpoints while still providing a reasonable grace period for temporary outages and recovery scenarios.
|
|
40
|
+
|
|
41
|
+
### How to enable
|
|
42
|
+
|
|
43
|
+
Open `config/environments/development.rb` and `config/environments/production.rb` and set `automatic_endpoint_deactivation_enabled` to `true`:
|
|
44
|
+
|
|
45
|
+
```ruby
|
|
46
|
+
config.outgoing_webhooks[:automatic_endpoint_deactivation_enabled] = true
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Optionally configure other related settings:
|
|
50
|
+
|
|
51
|
+
```ruby
|
|
52
|
+
config.outgoing_webhooks[:automatic_endpoint_deactivation_settings] = {
|
|
53
|
+
max_limit: 50,
|
|
54
|
+
deactivation_in: 3.days
|
|
55
|
+
}
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
### How it works:
|
|
59
|
+
|
|
60
|
+
1. **Normal Operation**: Webhooks are delivered normally to healthy endpoints
|
|
61
|
+
2. **Endpoint Failure**: When an endpoint becomes unavailable, webhook deliveries begin failing
|
|
62
|
+
3. **Delivery Attempts**: New webhook deliveries (WD1, WD2, WD3, etc.) are attempted but fail and trigger reattempts
|
|
63
|
+
4. **Exhaustion Tracking**: After ~25 hours, WD1 exhausts its reattempts and increments the endpoint's failed deliveries counter to 1
|
|
64
|
+
5. **Counter Increment**: As other delivery attempts become exhausted, the failed counter continues to increment
|
|
65
|
+
6. **Deactivation Mark**: Once the counter reaches the maximum threshold (`max_limit` config), the endpoint transitions to the "marked for deactivation" state
|
|
66
|
+
7. **Grace Period**: Additional deliveries may still be attempted for 3 days after the endpoint is marked for deactivation. The period can be configured with `deactivation_in` config.
|
|
67
|
+
8. **Final Deactivation**: After the `deactivation_in` grace period (3 days by default), the next delivery attempt to become exhausted will trigger the endpoint to be deactivated.
|
|
68
|
+
9. **Next Deliveries**: All future deliveries will be ignored and no attempt will be created. However, `deliveries` will still be created for debugging purposes and to ensure that the webhook was triggered.
|
|
69
|
+
|
|
70
|
+
### Recovery:
|
|
71
|
+
|
|
72
|
+
If any delivery is successfully delivered before the endpoint is deactivated (indicating the endpoint URL has recovered), the system will:
|
|
73
|
+
- Reset the endpoint's failed deliveries counter to 0
|
|
74
|
+
- Unmark the endpoint for deactivation
|
|
75
|
+
- Resume normal webhook delivery operations
|
|
76
|
+
|
|
33
77
|
## Future Plans
|
|
34
78
|
- Allow users to filter webhooks to be generated by a given parent model. For example, they should be able to subscribe to `post.created`, but only for `Post` objects created within a certain `Project`.
|
|
35
79
|
- Integrate [Hammerstone Refine](https://hammerstone.dev) to allow even greater configurability for filtering webhooks.
|
data/lib/bullet_train/version.rb
CHANGED