Skip to content

LoadState replay has no rollback: a poisoned saved state re-injects rejected entries forever #1313

Description

@FlorentinDUBOIS

Follow-up to #1312 (see the review discussion there).

The live AddHttpFrontend fan-out path has a unanimous-rejection rollback since #1301: compute_rollback maps AddHttpFrontendRemoveHttpFrontend (bin/src/command/requests.rs:2117), applied on unanimous worker failure (:2642), so the main's ConfigState is reverted and no phantom route persists.

The LoadState path has none of it: LoadStateTask carries no rollback field, requests.rs:3319 dispatches each request into ConfigState before scattering, and on_finish (:3392-3446) only tallies successes/failures. A saved state containing an entry every worker rejects (e.g. a malformed frontend hostname, now answered with Failure instead of a panic since #1312) is re-injected into ConfigState on every load, re-persisted by SaveState, and re-rejected by every worker on every replay — a permanent poison with an ERROR line per worker per load.

load_static_config (:890) has the same shape.

Suggested direction: validate before dispatch on the load path (same throwaway-Router idea as the #1301 listener validation, which also covers the DomainRule parse), and/or give LoadStateTask the same rollback the live path has.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions