Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/lessons.md
Original file line number Diff line number Diff line change
Expand Up @@ -506,3 +506,10 @@ The 5s drain is intentional: gives the worker thread a chance to escape `with lo
**Solution:** #329 fixed as a *garbage collector* rather than a rotator, with two guards — a file goes only when it is both older than `HIVE_LOG_RETENTION_DAYS` and its owning PID is gone, because age alone would unlink an idle-but-running daemon's open file and detach its inode on POSIX. #127 rescoped on-ticket with the corrected premise instead of being worked as written; `AGENTS.md` corrected, which also surfaced that widening the pin to `<3.0` silently lost the guard the narrow cap existed to provide.
**Why:** Read the mechanism before accepting the ticket's diagnosis — a title is a hypothesis written at a past moment, and the code is the only current statement of what is true. This matters most for tickets carrying a *dated instruction* ("if X by DATE, do Y"): the instruction keeps its authority long after its premise lapses, and following it feels like diligence. Cheapest check is to read the relevant docstring and the current pin, both of which contradicted the tickets here in under a minute. And when a stale fact has been copied into `AGENTS.md`, correcting the ticket is not enough — the copy is what every agent reads first.
**Tags:** `#diagnosis` `#tickets` `#documentation-drift` `#logging` `#mcp` `#HIVE-127` `#HIVE-329`

### [2026-08-07] A config filter that reads like "batch these" actually means "exclude the rest"
**Context:** A high-severity Dependabot advisory on `cryptography` ([#334](https://github.com/mlorentedev/hive/issues/334)) sat with no pull request. Filed with two candidate causes and no decision, then investigated.
**Problem:** Both stated hypotheses were wrong, and ruling them out is what exposed the real cause. *"The grouped weekly config with `open-pull-requests-limit: 1` starves security updates"* — no: `automated-security-fixes` was `enabled=true, paused=false`, and security updates are not subject to that limit. *"Transitive bumps are unreachable"* — no: `uv lock --dry-run --upgrade-package cryptography` resolved `48.0.1 -> 50.0.0` in 284 ms with nothing pinning it below 50, and Dependabot had **already** bumped this same transitive package in PR #137, touching only `uv.lock`. The difference between #137 and the stuck alert was the *update type*: #137 was a patch, this one a major. The cause was a group that reads as a batching convenience: `patterns: ["*"]` with `update-types: ["minor", "patch"]`. Because the pattern claims **every** dependency while the update-types admit only two, a major bump is not batched elsewhere — it is **excluded entirely**. `pip` and `npm` each had one such group, so neither Python deps nor the Astro site could receive a major bump at all, security or routine, and no major appeared anywhere in the repo's Dependabot history. `github-actions` and `docker`, which set no `update-types`, were unaffected.
**Solution:** A second group per affected ecosystem matching the same `*` but claiming `major` only — two groups with identical patterns are non-overlapping when their update-types are disjoint, so minor/patch stay batched while a major arrives as its own PR. Deliberately *not* adding `major` to the existing group, which would fold a breaking change in with routine patches and force an all-or-nothing merge. `open-pull-requests-limit` went 1 -> 2 so the groups do not compete for one slot, keeping the "no 20 stale PRs" property the config was written for. The analysis also recorded what it could not prove from outside — whether the group filter specifically suppressed the *security* path — because the fix is right on its own terms either way.
**Why:** An allow-list scoped by one axis (`update-types`) but matched by another (`patterns: ["*"]`) silently subtracts from the total. Read such a rule as "what does this make unreachable", not "what does this group together" — and check the complement explicitly. The diagnostic that worked was falsifying every stated hypothesis first: once both were dead, the one remaining difference between a working case (#137) and the broken one *was* the cause, with no guessing. Look for a past success of the same shape before theorising about a failure; it turns an open question into a controlled comparison.
Comment on lines +512 to +514

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

git log --format=%H -- .github/dependabot.yml | head -n 10 |
while IFS= read -r commit; do
  echo "== $commit =="
  git show "$commit:.github/dependabot.yml" 2>/dev/null |
    rg -n -A8 -B4 'groups:|applies-to:|patterns:|update-types:|open-pull-requests-limit:|ignore:' || true
done

Repository: mlorentedev/hive

Length of output: 7225


🌐 Web query:

GitHub Dependabot update-types groups affects version updates security updates applies-to default

💡 Result:

In GitHub's Dependabot configuration, the 'groups' feature allows you to combine multiple dependency updates into a single pull request [1][2]. These grouping rules are defined within your 'dependabot.yml' file [3][4]. The 'applies-to' parameter within a group definition determines whether the group rule applies to 'version-updates' or 'security-updates' [3][5]. If 'applies-to' is not explicitly defined, it defaults to 'version-updates' [3][1]. The 'update-types' parameter allows you to further filter dependencies within a group based on their semantic versioning (SemVer) level [3][6]. You can specify 'major', 'minor', or 'patch' [3][5]. By default, a group includes updates for all semantic version levels [3]. When configuring these options, note the following: - Security updates and version updates are never grouped together in the same pull request [7]. - You can create separate group definitions to handle security and version updates independently by specifying the 'applies-to' value for each [1][8]. - Dependabot evaluates group rules in the order they appear in the configuration file; a dependency is assigned to the first group for which it qualifies [2].

Citations:


Limit the exclusion claim to version updates.

Line 512 says the group excluded major updates “security or routine.” Dependabot groups default to version updates, and update-types does not affect security updates unless the group explicitly uses applies-to: security-updates.

Say the configuration excluded major version-update pull requests, and keep the security-update effect as unproven.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/lessons.md` around lines 512 - 514, Revise the documentation’s exclusion
claim to state that the configuration excluded major version-update pull
requests, not major security updates. In the discussion around the Dependabot
group analysis, retain security-update behavior as unproven unless explicitly
configured with applies-to: security-updates, while preserving the existing
explanation of routine major updates.

**Tags:** `#dependabot` `#dependencies` `#security` `#configuration` `#diagnosis` `#HIVE-334`