vectordotdev/vector · error
Enacted entry ' ' has removed_in ( ) that is not in a later…
Error message
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. What it means
`validate_enacted` enforces the deprecation policy: a feature must be announced for at least one minor release before removal. If parsed `removed_in` is not a strictly later minor than `deprecated_since` (checked via `later_minor`), it bails. This keeps removals from shipping in the same or earlier minor than the announcement.
Solutions
- Set removed_in to at least one minor release after deprecated_since (e.g. deprecated 0.45.0 -> removed 0.46.0 or later)
- If deprecated_since is wrong, fix it to the release where the deprecation was actually announced
- Remove prerelease suffixes from version fields so versions parse and compare correctly
- Re-run the validation check after adjusting versions
Example fix
// before --- what: old_option deprecated_since: 0.47.0 removed_in: 0.47.0 --- // after --- what: old_option deprecated_since: 0.47.0 removed_in: 0.48.0 ---
Defensive patterns
Strategy: validation
Validate before calling
fn later_minor(removed: (u64,u64), dep: (u64,u64)) -> bool {
removed.0 > dep.0 || (removed.0 == dep.0 && removed.1 > dep.1)
}
let dep = (0, 47); let rem = (0, 48);
assert!(later_minor(rem, dep), "removed_in must be a later minor than deprecated_since"); Try / catch
match result {
Err(e) if e.to_string().contains("not in a later minor release") => {
// bump removed_in (or fix deprecated_since) and re-validate
}
other => other?,
} Prevention
- When writing fragments, always set removed_in at least one minor above deprecated_since
- Double-check versions after automated version bumps in fragments
- Avoid prerelease suffixes in deprecated_since/removed_in fields
- Run the deprecation validation test suite before pushing
When it happens
Trigger: Calling `validate_enacted` (part of deprecation checks/tests) when an enacted entry has removed_in equal to, earlier than, or in the same minor as deprecated_since — including invalid prerelease versions that fail later_minor.
Common situations: Writing a fragment setting removed_in to the same release as deprecated_since; back-dating removed_in below deprecated_since during a version bump; using a prerelease version string that the comparison cannot order.
Related errors
- Conflicting enacted entry for
- Deprecation fragment
- Duplicate deprecation fragments for `what
- Duplicate enacted entry for
- fragment(s) have a deprecated_since version newer than the…
AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16).
Data as JSON: /api/errors/3f1f1cd7de25820b.
Report an issue: GitHub.
Appendix: source
Thrown at vdev/src/utils/deprecation.rs:380
/// in different releases)
pub fn validate_enacted(repo_root: &Path) -> Result<usize> {
let enacted = read_enacted(repo_root)?;
let mut seen: std::collections::HashSet<String> = std::collections::HashSet::new();
for e in &enacted {
let dep = parse_strict_release(&e.deprecated_since).with_context(|| {
format!(
"Enacted entry '{}' has invalid deprecated_since '{}'",
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.View on GitHub (pinned to bdb87aeaa4)