Misconfigured InMemoryStore cannot be recovered in recovery mode

Issues
1

Issue Description

If the user misconfigures the InMemoryStore, they cannot recovery from the broken configuration using the recovery mode, since even in recovery mode the api endpoint are still ratelimited, and the ratelimit implementation depends on the InMemoryStore to be properly configured.

Expected Behavior

User can enter the admin portal despite having a misconfigured InMemoryStore, and fix the configuration.

Actual Behavior

User cannot access the admin portal even in recovery mode.

Reproduction Steps

  1. bootstrap stalwart
  2. change the InMemoryStore configuration to something invalid, like a broken redis url
  3. try to recover from this situation by entering recovery mode

Relevant Log Output

ERROR Store not configured (store.not-configured) listenerId = "http-recovery", localPort = 8080, remoteIp = <redacted> remotePort = 50956, causedBy = "crates/store/src/dispatch/lookup.rs:111", causedBy = "crates/store/src/dispatch/lookup.rs:317", causedBy = "crates/common/src/auth/rate_limit.rs:35

Stalwart Version

v0.16.x

Installation Method

NixOS

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Confirmed as a bug in the current code path: recovery mode still runs the HTTP rate limiter, and is_http_anonymous_request_allowed / is_http_authenticated_request_allowed in crates/common/src/auth/rate_limit.rs unconditionally call self.core.storage.memory.is_rate_allowed(...), which uses the configured InMemoryStore (e.g. Redis) for lookups. If that store is misconfigured, the lookup errors out with store.not-configured, and since there is no exemption for the recovery listener, the request fails before authentication is even attempted, blocking access to the WebUI/JMAP API on the recovery port.

The recovery mode docs describe it as disabling all background services and MTA processing so the admin can fix config via WebUI/CLI, but they don’t mention any exemption from HTTP rate limiting, and the source shows none exists: Recovery mode | Stalwart

This looks like a genuine gap rather than a documented workaround, so a human/staff member will need to follow up on fixing the rate limiter to skip enforcement (or fail open) when running under STALWART_RECOVERY_MODE.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.13 which will be released this week.