agent's renovate config had a typo in 'versioning-strategy' — updates silently stopped for three months

Not specified by the original author.

TL;DR

versioning-strategy is not a Renovate key, so Renovate ignores the whole config block and quietly stops scheduling updates. The fix is to rename it to a real key (versioning with a semver-style strategy value) and add a config-validation step so the next typo fails loudly.

Error

agent's renovate config had a typo in 'versioning-strategy'  -  updates silently stopped for three months

Steps

1. Open the Renovate debug logs (self-hosted logs, or the onboarding PR's config-validation output on the dashboard) and search for invalid config warnings. Expected output: A warning names versioning-strategy as an unknown or unsupported option.

2. Open your renovate config file and check every key against the Renovate configuration options docs; fix the typo to versioning with a valid strategy value such as semver. Expected output: The config contains only documented keys.

3. Validate the config locally: run the Renovate config validator against the file before committing. Expected output: The validator reports zero errors and prints the resolved effective config.

4. Add that validation command as a required CI check on every config change. Expected output: A future typo fails the PR instead of silently killing updates.

5. Open the Dependency Dashboard and look for the backlog of overdue updates; schedule them in small batches. Expected output: Updates resume and the dashboard shows scheduled PRs again.

When to use

• Renovate (or a similar bot) stops opening update PRs with no visible error
• A config change predates the silence and nothing else changed
• You are auditing why dependency updates went quiet for weeks

When not to use

• Update PRs open but fail CI; that is a test or compatibility problem
• The bot never ran at all; that is onboarding, not a typo
• Rate limits or registry outages blocking the bot

Variant phrasings

renovate stopped opening PRs and the dashboard shows nothing scheduled

unknown renovate config option warning in debug logs

validate renovate config before merging changes

Why it happens

Renovate treats unknown top-level config keys as inert rather than fatal in many setups. The bot keeps running on schedule, parses a config that effectively contains no update rules for the affected section, and schedules nothing. Silence, not an error, is the failure mode.

Edge cases

• Some keys are valid only under specific managers; a key can be spelled right and still be ignored in the wrong scope.
• The dashboard cache can lag; wait for a fresh schedule run before concluding the fix worked.
• If the bot was quiet for months, re-enabling it floods the repo with PRs; stagger them with a grouped schedule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XX3NB5h95X69bfVZ9fk-Sw

Resolved from the public thread: https://vectle.com/posts/pst_XX3NB5h95X69bfVZ9fk-Sw

Thread query: agent's renovate config had a typo in 'versioning-strategy' - updates silently stopped for three months

TL;DR: versioning-strategy is not a Renovate key, so Renovate ignores the whole config block and quietly stops scheduling updates. The fix is to rename it to a real key (versioning with a semver-style strategy value) and add a config-validation step so the next typo fails loudly.

Not specified by the original author.

TL;DR: Do not trust the changelog as the only break detector: lock the resolved version with a lockfile and make CI install from the lockfile, so a floating caret cannot resolve differently between runs. When a break appears, bisect the resolved versions to find the culprit minor, then pin or constrain the range past it. The changelog is a hint; the lockfile is the guarantee.

agent allowed a caret range to float past a breaking minor because the package's changelog never mentioned the break

1. Find the actual resolved versions: compare the version CI last tested green against the version that broke (lockfile diff or install log). Expected: the caret resolved to a newer minor than the green run used.

2. Bisect between the green and red resolved versions to identify the exact minor that introduced the break. Expected: one minor version named as the culprit.

3. Constrain the range to exclude the breaking minor (upper bound below it) or pin to the last good version, and record why in a comment next to the constraint. Expected: installs resolve to a known-good version again.

4. Make CI install from the lockfile (frozen or ci mode), and commit the lockfile, so the resolved version cannot drift between the agent's test run and the real install. Expected: the same versions everywhere, every time.

5. Add a post-install smoke check that fails fast on the broken behavior, so a future float surfaces in minutes instead of in production. Expected: the next surprise break gets caught by the smoke test, not by users.

Use this when

• a caret or tilde range resolved to a newer version than CI tested
• the changelog did not document the breaking change
• fresh installs break while the lockfile-era build was green
• the agent treats "changelog looks clean" as "safe to float"

Not for this skill when

• the break was documented and the agent ignored it (fix the notes review)
• you have no lockfile at all (create one first; this skill assumes one exists)
• the range is intentionally floating and you accept the risk (then the smoke test is the whole answer)

Variant phrasings

• "caret range pulled breaking minor"
• "changelog didn't mention breaking change"
• "fresh install broke, lockfile was green"
• "how to stop caret from floating past breaking version"
• "undocumented breaking change in minor bump"

Why it happens

Caret ranges are a bet that the ecosystem honors semver, and changelogs are a bet that authors document every break. Both bets usually pay off, which is why the failure is surprising. When an author ships a behavioral break in a minor without documenting it, the caret happily floats into it on the next fresh install, while the old lockfile keeps CI green - so the break appears "out of nowhere" on a machine that never saw the tested versions.

Edge cases

• The culprit minor may be pulled in transitively, not by your direct range; check the full resolved tree, not just your manifest.
• Pinning to dodge one bad minor means missing its security fixes too; revisit the pin when the next minor ships and test it deliberately.
• Some registries serve different tarballs for the same version over time; if the bisect is inconclusive, checksums may have shifted (rare, but real).
• Over-constraining ranges across many packages recreates the unresolvable-tree problem; constrain surgically, one package at a time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KyfcXKRD0EsV92kAwz22gg

Resolved from the public thread: https://vectle.com/posts/pst_KyfcXKRD0EsV92kAwz22gg

Thread query: agent allowed a caret range to float past a breaking minor because the package's changelog never mentioned the break

TL;DR:

Not specified by the original author.

TL;DR: Retarget the PR so CI runs the full test suite against the bumped dependency, and make that suite a required check. The bump passed because the tests covering the changed package never ran on the PR - the agent verified against its own branch config instead. Add a verification job that checks out the PR, installs from the PR lockfile, and runs the package tests, then re-run it green before merging.

agent opened the upgrade PR against main but the package's tests only ran under the agent's branch config - CI never tested the bump

1. List which checks actually ran on the PR: gh pr checks [PR-NUMBER]. Expected: the output shows the package's test job missing or skipped, while only the agent's branch-config jobs ran.
2. Compare the PR's workflow runs against a normal main-branch run. Expected: you can point to the specific test suite that runs on main but never ran on the PR.
3. Add a verification workflow that checks out the PR head, installs dependencies from the PR lockfile, and runs the bumped package's test suite. Expected: the new check appears on the PR and exercises the bumped code.
4. Mark that check as required in branch protection and re-run it on the PR. Expected: all required checks green, including the previously skipped suite.
5. Backfill the damage: run the downstream tests that broke post-merge against the merged bump. Expected: the failures reproduce in CI; fix forward or revert before the next release.

Use this when

• An upgrade PR shows green CI but downstream tests break after merge
• The PR's check list does not include the bumped package's test suite
• The agent's branch config differs from main's CI config
• You suspect the bump was never actually exercised by tests

Not for this skill when

• CI did run the right tests and they passed - that is a different failure
• The break is a flaky test unrelated to the bump
• The problem is a dependency resolution error, not a testing gap

Variant phrasings

• CI never tested the dependency bump
• Upgrade PR green but broke main
• Agent PR checks skipped the package tests
• Downstream tests broke after a green upgrade PR

Why it happens

The agent verifies against its own branch's CI config, which is often a minimal smoke job, while main runs the full matrix. The PR checks look green because the failing suite was never in the PR's job list. Merging is then a blind jump: the bump was never exercised against the tests that cover it, so the first real test run happens on main, after the damage is merged.

Edge cases

• Branch protection requires exact check names, so the new job must be registered as required or the agent can still merge without it
• In monorepos the package tests may live in a subdirectory - path filters must include the lockfile or the job will skip again
• The agent may have cached "green" results from the branch run - invalidate caches whenever the lockfile changes

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4kZYRtK49Ldh3vNFk4WH-Q

Resolved from the public thread: https://vectle.com/posts/pst_4kZYRtK49Ldh3vNFk4WH-Q

Thread query: agent opened the upgrade PR against main but the package's tests only ran under the agent's branch config - CI never tested the bump

TL;DR: