HTTP injection with long From display names

KumoMTA Policy
22

Should be, same config works with the stable release. Currently testing sha-c79723d locally

23 

thread 'httpinject-1' (41) panicked at crates/spool/src/lib.rs:68:16:
set_meta_spool has not been called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'httpinject-2' (42) panicked at crates/spool/src/lib.rs:68:16:
set_meta_spool has not been called

thread 'httpinject-2' (42) panicked at crates/spool/src/lib.rs:68:16:
set_meta_spool has not been called
2026-02-10T03:14:33.496602Z DEBUG localset-1 kumod::spool: starting maintainer for spool data is_meta=false
2026-02-10T03:14:33.496757Z DEBUG localset-1 kumod::spool: starting maintainer for spool meta is_meta=true
2026-02-10T03:14:33.497081Z DEBUG localset-1 kumod::spool: start_spool: waiting for enumeration
2026-02-10T03:14:33.497891Z  INFO localset-1 kumod::spool: Using concurrency 5 for spooling in
2026-02-10T03:14:33.498273Z DEBUG localset-1 kumod::spool: starting spool memory monitor
2026-02-10T03:14:33.501949Z DEBUG localset-1 kumod::logging::classify: Reloading the bounce classifier for epoch ConfigEpoch(2)
2026-02-10T03:14:33.950471Z DEBUG  spoolin-2 kumod::spool: expiring e6b9b8af05bc11f1a29b3a1632662f76 13h 34m 2s 696ms 495us 376ns > 12h
2026-02-10T03:14:33.951410Z DEBUG bounce-classify kumod::logging::classify: classifier applying new epoch ConfigEpoch(2)
2026-02-10T03:14:33.952907Z  INFO      localset-1 kumod::spool: start_spool: enumeration done, spooled in 1 msgs over 455.813956ms 3/s```
24

and in the init.lua for local testing:

    name = 'data',
    path = '/var/spool/kumomta/data',
    min_free_space = '0%',
    min_free_inodes = '0%'
  }

  kumo.define_spool {
    name = 'meta',
    path = '/var/spool/kumomta/meta',
    min_free_space = '0%',
    min_free_inodes = '0%',
  }```
25

Switched to sha-c9ae7b5 which does work! So either 9eeca8de4b6434ca5a79f0251b86ef7af2c58ea9 dbd6d85b64cd8d0e79187cb3ed7a6e4b0690c68e or c79723d6efa6a4ebd5d8e3af64aafa74d66e1ef6 have been the issue.

I am however on holiday with very, veeeeery slow LTE in the pacific haha, but wanted to try it out some more. So I’ll be able to test later

26

Ah, I see; it’s an early startup race condition. Your injectors are sending while the system is starting up, and the http injection code path isn’t returning an error like we’d do for smtp. http injection: fix early startup race condition w/ spool · KumoCorp/kumomta@188356e · GitHub fixes that.

27

Awesome will try it out! Fix for the from display names works great btw! Thanks

28

By the way, if KUMOMTA is restarting, can new requests still come in?
My understanding is that it would be best to allow new requests only after Kumo has fully started.
However, even if no new requests are accepted, historical messages will still be loaded from the spool into memory for delivery.

29

Hmm, I noticed that this was something else that didn’t match up to how we process SMTP, so I fixed that up in http/xfer injection: grab Activity handle for duration of request · KumoCorp/kumomta@6193331 · GitHub

I will note that most folks using this at scale have a load balancer that checks GET /api/check-liveness/v1 - KumoMTA Docs so that they don’t select nodes that are shutting down, so we haven’t had anyone report that issue in practice.