stamparm/maltrail · error · SystemExit

[!] no VERSION constant found in

Error message

[!] no VERSION constant found in %s

What it means

settings_gen_version parses the generated Rust mirror of core/settings.py for `pub const VERSION: &str = "..."`. If the generated file is missing that constant (stale, regenerated from a modified template, or truncated), the tool exits with this message instead of reporting a bogus version. This is the text-based gate that keeps a failed release from being tagged.

Solutions

1. Regenerate the settings mirror from core/settings.py with the project's generator so VERSION is emitted
2. Verify settings.py still defines VERSION and the generator template still contains the `pub const VERSION` line
3. Check the file for truncation or hand edits and restore `pub const VERSION: &str = "3.2";`
4. Re-run check_version.py to confirm the gate passes

Example fix

// before (generated settings mirror missing constant)
// no VERSION constant
// after
pub const VERSION: &str = "3.2";

import re, pathlib
text = pathlib.Path(SETTINGS_GEN).read_text()
assert re.search(r'^pub const VERSION: &str = "[^"]+";', text, re.M), "generated settings missing VERSION"

When it happens

Trigger: Running check_version.py when the generated settings mirror (SETTINGS_GEN) lacks a `pub const VERSION: &str = "...";` line — e.g. the generator template changed, the file was regenerated from a settings.py that removed VERSION, or the file is truncated/partially generated.

Common situations: A refactor renamed or removed the VERSION constant from settings.py before regenerating; the build script wrote a partial file mid-failure; someone hand-edited the generated file and broke the constant declaration syntax.

Understand the failure class

Background: "is required", "must be set", "missing required field": configuration validation errors across open-source libraries — this error's family across 36 libraries.

Related errors

• [!] no maltrail-sensor package entry found in
• [!] no version key found in
• [!] not built - cargo build --release --manifest-path…
• [x] invalid IP address
• not a Maltrail provenance sidecar (bad magic)

AI-assisted analysis of stamparm/maltrail@77cfb06d76 (2026-09-13). Data as JSON: /api/errors/77aea75c94eef42b. Report an issue: GitHub.

Appendix: source

Thrown at sensor/tools/check_version.py:86

    match = re.search(r"^version\s*:\s*[\"']([^\"']+)[\"']", _read(CITATION), re.M)
    if not match:
        raise SystemExit("[!] no version key found in %s" % CITATION)
    return match.group(1)


def settings_gen_version():
    """pub const VERSION: &str = "3.2"; from the generated mirror of core/settings.py.

    This is a FOURTH place the version lives, and it was the one nobody checked here. The Rust
    parity test covers it, but that test needs a Rust toolchain - so the automated monthly bump,
    which is a text edit on a machine that has none, could not tell it had gone stale. It found
    out from a failed release: the tag was already pushed, the gate refused it, and nothing was
    built. A version bump is text; verifying it should be text too.
    """

    match = re.search(r'^pub const VERSION: &str = "([^"]+)";', _read(SETTINGS_GEN), re.M)
    if not match:
        raise SystemExit("[!] no VERSION constant found in %s" % SETTINGS_GEN)
    return match.group(1)


def cargo_lock_version():
    """The maltrail-sensor entry in sensor/Cargo.lock.

    A FIFTH place, and the release builds with --locked: a lock that still names the old version
    does not warn, it refuses to build.
    """

    match = re.search(r'name = "maltrail-sensor"\nversion = "([^"]+)"', _read(CARGO_LOCK))
    if not match:
        raise SystemExit("[!] no maltrail-sensor package entry found in %s" % CARGO_LOCK)
    return match.group(1)


def series(version):
    """'3.0.1' and '3.0' both reduce to (3, 0) - Maltrail versions two components, Cargo three.

View on GitHub (pinned to 77cfb06d76)