triage-unassigned-bfs

Files (1)

• SKILL.md

SKILL.md (first lines)

# Triage Unassigned BFs

Tooling: Always use the Jira MCP tools on `user-devprod-mcp-gateway` for BF triage; do **not** use the `jira` CLI for this skill. If the Jira MCP returns an auth or gateway issue, stop and report back to the user; do not continue with fallbacks. Glean MCP may miss Jira tickets due to stale indexing, so use it only as supplemental context after the Jira MCP succeeds, never as the source of truth for ticket discovery.

Two-phase workflow. **Always run Phase 1 first.** Only run Phase 2 if the user explicitly asks for owner suggestions or confirms after seeing the Phase 1 list.

## Source board (fixed)

Static board: <https://jira.mongodb.org/secure/Dashboard.jspa?selectPageId=32941> — scopes to the **Catalog and Routing** team's open BFs. Use the JQL templates below directly; do **not** ask the user for a filter URL, JQL, or team name. Only override the team name if the user explicitly says so.

---

## Phase 1 — List unassigned BFs

Use `jira_search_issues` (`user-devprod-mcp-gateway`) to query unassigned non-resolved BFs, split by temperature (run once with `hot`, once with `cold`):

```
project = BF
  and status not in (Resolved, Closed)
  and assignee is EMPTY
  and Temperature ~ "<hot|cold>"
  and "Assigned Teams" = "Catalog and Routing"
```

**JQL gotcha**: `Temperature` only supports `~`, not `=` (HTTP 400 otherwise).

### Output format

Two sections, each a table sorted by **Priority desc, then Created desc** so the most actionable items lead.

**Only list non-Trivial-P5 BFs in tables.** Trivial-P5 BFs (including ones tagged `keep-trivial*`, `not-*-blocker`, `oldshardingemea`, etc.) are noise for triage — collapse them into a single trailing count line per section. Do not list keys, do not give them rows.

```
🔥 Unassigned hot BFs (<count>)

| BF | Priority | Status | Test / Task | Created |
|---|---|---|---|---|
| BF-XXXXX | Major-P3 | Waiting for bug fix | foo.js / sharded_jscore | 3d ago |

_+ <N> Trivial-P5 hot BFs not shown._

🧊 Unassigned cold BFs (<count>)

| BF | Priority | Status | Test / Task | Created | Note |
|---|---|---|---|---|---|
| BF-YYYYY | Major-P3 | Open | bar.js / concurrency | 3d ago | ⚠️ non-trivial |

_+ <N> Trivial-P5 cold BFs not shown._
```

If a section has **no non-trivial BFs**, omit the table and just print the trivial count line — and explicitly call out that there is nothing actionable in that section.

**Always flag non-Trivial-P5 cold BFs with ⚠️** — they deserve a real owner. Do not bury them in a paragraph (lesson learned: a Major-P3 cold BF is the headline, not a parenthetical).

After the tables, ask: *"Want me to suggest owners (Phase 2)?"*

---

## Phase 2 — Suggest owners

Run only after Phase 1 if the user asks. Different strategies for hot vs. cold. For any non-trivial BF, the **fixed pre-flight order** is:

1. **Duplicate check** (below) — same root cause as another BF?
2. **Team-fit / mis-routing check** (below) — does the failure even belong to our team, or is the BF auto-assigned to us only because the failing suite is owned by us?
3. **Owner search** (hot: code blame; cold: load-balance) — only run this once steps 1 and 2 don't fully dispose of the BF.

If step 1 or step 2 dispose of the BF, **stop** — don't suggest a teammate. Re-route or link-as-duplicate instead.

### Mandatory duplicate check (non-trivial BFs)

A **duplicate** here means: two BFs likely share the **same core issue**, such that the same fix would probably apply to both. Do **not** require the same exact test, task, or team. Do **not** prove via deep log analysis (too expensive); infer from **error symptoms** + **execution conditions**.

After `jira_get_issue` succeeds, use Glean MCP (`user-glean_default`) as supplemental context together with Jira fields:

1. Use `jira_get_issue` for the BF, especially to read: `Failing Tests`, `Failing Tasks`, `Failing Buildvariants`, `Bug Symptoms`, `Last Comment`, `Dependencies`, `Fix Revision` (if present).
2. First `search`: short, discriminative failure-signature keywords — BF key (e.g. `BF-42857`), failing test basename (e.g. `change_stream_future_start_time_new_shard.js`), core error fragment (e.g. `A shard named newShard already exists`).
3. Second `search`: failing task/buildvariant + error fragment.
4. If neither surfaces a convincing candidate, run a **symptom-family pass**:
   - Normalize the symptom before searching; keep the durable signal, drop incidental wording.
   - Examples: reduce `No progress was made executing write ops in after 5 rounds (6 rounds total)` and `no progress was made executing bulkWrite ops in after 5 rounds (0 ops completed in 9 rounds total)` to the same family: `NoProgressMade`, `bulk write`, `code 82`. Ignore exact round counts, document ids, hostnames, and `/data/mci/...` path prefixes.
   - Search on the condition bundle, not just the test name: suite/task family; operation family (`movePrimary`, `bulkWrite`, `stepdown`, `unsplittable`, etc.); environment hints that materially affect behavior.
5. `read_document` on top candidate URLs to verify the **symptoms + conditions** line up.
6. Explicitly inspect whether any linked fix/dependency on the candidate BF plausibly applies to the current BF — best cheap proxy for "same core issue."
7. Use `chat` only when synthesis across several candidate sources is needed.

Heuristics:

- Different failing tests do **not** disqualify a duplicate if the symptom family and execution conditions still point to the same bug.
- Different teams do **not** disqualify a duplicate; some bug families cross ownership boundaries.
- A shared generic error alone is **not** enough. `NoProgressMade` or `code 82` by itself only says "same symptom family," not "same root cause."
- Prefer an older BF with a linked fix ticket whose fix description matches the current BF's conditions over a newer BF that only shares a string fragment.
- **Suite-disable / test-skip fixes are sticky.** If a recently-closed BF on the **same suite** with an overlapping test-family was fixed by disabling those tests (e.g. `SERVER-XXX Disable <family> tests in <suite>`), a new BF on the same suite touching any test in that family is almost certainly the same issue — even if the literal exception text differs (one run may surface as a primary assertion, another as a teardown error). Look for a `Dependencies` / `Fix Revision` like `Disable …` or `Skip …` on the candidate BF; that's a high-confidence dup signal.

Confidence rubric:

- **High ("likely duplicate")** — all of: same normalized symptom family; similar execution conditions (same suite/task family, operation family, failover pattern, or other meaningful scenario overlap); candidate BF's known fix/dependency/root-cause notes plausibly apply to the current BF.
- **Medium ("possible duplicate")** — symptom family matches and conditions look related, but fix applicability is still uncertain.
- **Low** — only generic symptom overlap, or conditions/root-cause notes point in different directions; explicitly say no clear duplicate found.

When high confidence, state certainty plainly, link the suspected duplicate ticket(s), and name the fix ticket if one exists. When medium, say whether it looks like a real duplicate or merely the same symptom family.

### Mandatory team-fit / mis-routing check (non-trivial BFs)

Run **after** the duplicate check, **before** any commit blame. BFs are often auto-assigned to the team that owns the failing suite, even when the actual failure has nothing to do with that team's code. Catching this saves the team a useless triage round and gets the BF to the right owner faster.

A BF is **likely mis-routed** if any of these hold:

- `Failure Type` is `system-failed` and `Bug Symptoms` contains test-runner / infra strings such as:
  - `No test results found for target … in 'build_events.json'`
  - `fetch remote test results` / `One or more shards had TIMEOUT or NO_REPORT status` (where "shards" are Bazel test shards, not DB shards)
  - `validating expanded params: AWS key cannot be blank` / `s3.get` / `s3.put` failures
  - `Failed to import a dependency … the task did not initialize the venv`
  - `subprocess.exec … in block 'post' failed: process encountered problem: exit code 127`
  - any Evergreen `Command 'X' in function 'Y'` failure where `Y` is a generic Evergreen function (`do setup`, `fetch …`, `upload …`, `cleanup …`, `kill processes`)
- `Failing Tasks` contains many unrelated tasks across many unrelated suites (a sign the failure hit at the runner / variant level, not in any one suite's code).
- `Failing Buildvariants` is dominated by one variant (often a `*-required` or `*-compile-required` variant) and the buildvariant — not the suite — is the common factor across recent occurrences.
- `First Failing Revision` is a commit that touches files clearly unrelated to the failing suite (e.g. a search/disagg or unrelated component change that wouldn't plausibly affect a sharding suite).
- The error contains no MongoDB-side stack frame, assertion, fassert, invariant, or `src/mongo/...` source pointer.

From enricogolfieri/workspace-mongo, Unlicense.

More from enricogolfieri/workspace-mongo