Do shaping rules apply to webhook queues?

get-help
1

Noticed that webhooks are delivering much slower than they could be, probably because max connections do not exceed 10 (default connection_limit from shaping.toml).

However, adding a shaping rule to shaping.toml to override the limit:

connection_limit = 50
max_connection_rate = "10000/min"

Results in this error:

Any advice?

2

Hey there @nourishing-urial, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.

3

the shaping helper should work; I’d suggest setting mx_rollup = false in that block, to prevent trying to resolve the MX for it

4

That solved MX lookup error, thanks. But it seems that TSA rules are not being applied to webhook queues, probably because these queues don’t have a domain.

5

I figure the only way to solve it would be to a make a copy of log_hooks helper, assign some fake placeholder domain to the queue, and then use that in TSA config? Or is there a more elegant way of solving that?

6

they already have a fake placeholder domain; webhook-clickhouse.log_hook in your example. I suspect that something else is happening here, but there’s not enough information to guess at what

7

The hook is defined using standard log_hooks.lua helper:

  name = 'webhook-clickhouse',
  url = 'http://10.11.11.3:8123/?async_insert=1&wait_for_async_insert=1',
  log_parameters = {
    headers = { 'X-Campaign', 'X-Tenant' },
    per_record = {
        Any = {
            enable = true,
            template = [[INSERT INTO kumomta_json_raw VALUES (generateULID(), '{{ log_record | tojson }}')]]
        }
    }
  },
}```
8

shaping.toml contains this rule:

connection_limit = 50
max_connection_rate = "10000/min"
mx_rollup = false```
9

What TSA rule are you expecting to take effect for this webhook? TSA rules are reactive based on feedback. Maybe share your automation rules?

10

here’s the entire shaping.toml
message.txt (4.85 KB)

11

It’s pretty much standard apart from the hook definitions.

12

I think we narrowed down the issue to active queue becoming exhausted, since the webhooks deliver faster than emails

13

and then the system pauses until active queue gets refilled again from the scheduled queue

14

So we increased max_ready parameter to account for that, and testing the setup further

15

The only automation I see there is the default.
Which of these were you expecting to be triggered?

        '/All messages from \d+\.\d+\.\d+\.\d+ will be permanently deferred/',
        '/has been temporarily rate limited due to IP reputation/',
        '/Unfortunately, messages from \d+\.\d+\.\d+\.\d+ weren.t sent/',
        '/Server busy\. Please try again later from/'```