Duplicate enacted entry for

Error message

Duplicate enacted entry for '{}'; the same feature cannot be recorded as removed more than once.

What it means

vdev's deprecation tooling enforces that each deprecated feature appears at most once in the enacted-removals list. During validate_enacted, each entry is inserted into a `seen` HashSet; if `insert` returns false the same `what` value was already recorded, and validation bails. This prevents double bookkeeping of a feature removal (e.g. two entries with differing removed_in dates) from silently corrupting the generated deprecation data.

Solutions

Remove or merge the duplicate entry so each feature's `what` appears exactly once in the enacted list
If two entries have different dates, keep the correct one and delete the stale copy
Run validate_enacted again to confirm the list is unique

Example fix

// before
[[enacted]]
what = "old_transform"
removed_in = "0.40.0"
[[enacted]]
what = "old_transform"
removed_in = "0.41.0"
// after
[[enacted]]
what = "old_transform"
removed_in = "0.41.0"

Defensive patterns

Strategy: validation

Validate before calling

let names: Vec<&str> = enacted.iter().map(|e| e.what.as_str()).collect();
let dupes: Vec<&str> = names.iter().filter(|n| names.iter().filter(|m| m == n).count() > 1).map(|n| *n).collect();
if !dupes.is_empty() { return Err(format!("duplicate enacted entries: {:?}", dupes)); }

Try / catch

match validate_enacted(&enacted) {
    Err(e) if e.to_string().contains("Duplicate enacted entry") => {
        eprintln!("Fix duplicate deprecation entry: {e}");
    }
    Err(e) => return Err(e),
    Ok(n) => println!("{n} enacted entries validated"),
}

Prevention

Keep one canonical entry per feature; edit dates in place rather than adding new entries
Check for duplicated entries after every merge/rebase of deprecation metadata
Add a CI check that fails on duplicate `what` values before validation runs

When it happens

Trigger: Calling validate_enacted when the enacted list contains two entries whose `what` field is the identical string — e.g. the same feature listed twice with different removed_in or deprecated_since values, or a merge/patch that duplicated a line.

Common situations: Hand-editing or code-generating the deprecation metadata and accidentally duplicating an entry; rebasing/merging two branches that each added an entry for the same feature; copy-pasting an entry to update its date instead of editing the existing one.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16). Data as JSON: /api/errors/1c7199968753ed25. Report an issue: GitHub.

Appendix: source

Thrown at vdev/src/utils/deprecation.rs:388

                e.what, e.deprecated_since
            )
        })?;
        let rem = parse_strict_release(&e.removed_in).with_context(|| {
            format!(
                "Enacted entry '{}' has invalid removed_in '{}'",
                e.what, e.removed_in
            )
        })?;
        if !later_minor(&rem, &dep) {
            bail!(
                "Enacted entry '{}' has removed_in ({}) that is not in a later minor release than deprecated_since ({}); the deprecation policy requires at least one minor release between announcement and removal.",
                e.what,
                e.removed_in,
                e.deprecated_since
            );
        }
        if !seen.insert(e.what.clone()) {
            bail!(
                "Duplicate enacted entry for '{}'; the same feature cannot be recorded as removed more than once.",
                e.what
            );
        }
    }
    Ok(enacted.len())
}

/// True when `a` is in a later major.minor release than `b`. Equal or smaller
/// major.minor (regardless of patch) returns false.
pub fn later_minor(a: &Version, b: &Version) -> bool {
    (a.major, a.minor) > (b.major, b.minor)
}

/// Parse a release version string strictly: only plain `X.Y.Z` is allowed
/// (no prerelease or build metadata). Mirrors the rule that release tags
/// follow `vX.Y.Z`.
pub fn parse_strict_release(s: &str) -> Result<Version> {

View on GitHub (pinned to bdb87aeaa4)