Files
kumomta/docs/reference/events/throttle_insert_ready_queue.md
T
Wez Furlong d063c96b5f yell loudly when sig.register() should have been called
A number of our lua event handlers allow registering multiple
implementations to facilitate modular use.

For that to work, we must know ahead of the user lua call running
that any given handle is allowed to register multiple times.  This is so
that we can report a meaningful error when incorrectly using a singleton
handler multiple times, and so that we can record a list of handlers
for the multiple case.

Prior to this commit, if we forgot to arrange to register the signature
as part of the context setup the consequence was that the event handler
would get registered as a singleton and when we went to call it, because
the signature is marked as allowing multiple but was not registered
as multiple, we would skate through and do nothing without reporting
an error because we assumed that the signature was registered
consistently.

In hindsight, that's a terrible idea because it results in silently
ignoring the registration issue, and not calling the event handler
at all.

This commit consolidates the multiple/single value resolution into
the same flow, then adds a check to confirm that we have a list
of handlers registered for the allow_multiple case, raising an
error otherwise that will hopefully encourage users to report
this problem to us if it manifests again in the future.

This commit includes fixing two event handlers that we missing
their signature registration.

One of them was broken anyway by being registered with a name
that didn't match the docs.

refs: https://github.com/KumoCorp/kumomta/issues/236
2024-10-07 10:25:47 -07:00

1.8 KiB

kumo.on('throttle_insert_ready_queue', function(message))

{{since('dev')}}

!!! note This event was actually added in 2024.06.10-84e84b89 but with a broken event registration that prevented it from working. That was corrected in the version shown above.

This event is triggered when a message is ready to move from its containing scheduled queue and into a ready queue.

Its purpose is to allow you to evaluate any throttles defined by your policy; see kumo.make_throttle() for more information on throttles.

Multiple instances of the throttle_insert_ready_queue event can be registered, and they will be called in the order in which they were registered, until all registered events are called, or until one explicitly returns nil to signal that no more should be triggered.

The example below will limit each tenant to send no more than 1000 messages per hour:

kumo.on('throttle_insert_ready_queue', function(msg)
  -- limit each tenant to 1000/hr
  local tenant = msg:get_meta 'tenant'
  local throttle = kumo.make_throttle(
    string.format('tenant-send-limit-%s', tenant),
    '1000/hr'
  )
  throttle:delay_message_if_throttled(msg)
end)

This example allows each tenant to have an individual limit; you could load the limits from a data file or database if you prefer.

local function per_tenant_throttle(tenant_name)
  -- default to 1000/hr unless otherwise overridden
  local rate = '1000/hr'
  if tenant_name == 'tenant_1' then
    -- Allow increased rate for this tenant
    rate = '10000/hr'
  end
  return kumo.make_throttle(
    string.format('tenant-send-limit-%s', tenant_name),
    rate
  )
end

kumo.on('throttle_insert_ready_queue', function(msg)
  local tenant = msg:get_meta 'tenant'
  local throttle = per_tenant_throttle(tenant)
  throttle:delay_message_if_throttled(msg)
end)