chore(backend): drop the stale no-untyped-def mypy override for core.node.base

[saltas888]

Summary

Removes the no-untyped-def mypy suppression on infrahub.core.node.base, restoring untyped-def checking on that module.

The module is already fully annotated — every def in backend/infrahub/core/node/base.py carries parameter and return types. The per-module override in pyproject.toml was therefore stale: it changed nothing about the current code and only served to hide future regressions. No source change was needed.

Resolves INBOX-30.

Changes

• pyproject.toml — delete the [[tool.mypy.overrides]] block for module = "infrahub.core.node.base" (disable_error_code = ["no-untyped-def"]).

That is the entire diff: pyproject.toml | 6 ------.

Testing

Re-verified on the current head (a6c76a1e, after the merge from develop):

Check	Result
uv run mypy --show-error-codes backend	Success — no issues found in 1610 source files
uv run invoke backend.lint (ruff, ty, mypy)	All checks passed
uv run invoke backend.test-unit	2233 passed
uv run invoke backend.validate-generated	No drift
uv lock --check	Lockfile in sync
CI on a6c76a1e	41 passed, 15 skipped, 0 failed

Enforcement verified, not just assumed. To confirm the removal actually takes effect and is not shadowed by a broader override (infrahub.core.node is a separate entry and does not cover submodules), an untyped def was temporarily appended to the module:

backend/infrahub/core/node/base.py:69: error: Function is missing a type annotation  [no-untyped-def]

mypy flagged it as expected; the probe was then reverted (the diff above is the whole change).

Status

• CI is fully green on a6c76a1e. The earlier red runs on this PR were never caused by its diff: python-lint was broken on develop itself (fixed independently by Add ruff exception for broad exception #10147), and the remaining failures were Actions infrastructure (queued-then-cancelled jobs, one OOM, one Neo4j deadlock at test setup). All resolved by the rebase @ogenstad asked for.
• @ogenstad's approval is stale — it was recorded against aa469642c, before that rebase and the subsequent develop merge, so GitHub no longer counts it. A fresh look is needed before merge; review re-requested.
• A changelog fragment was added initially and then dropped — a [[tool.mypy.overrides]] removal has no user-visible effect, so it does not warrant a release note.

🤖 Generated with Claude Code

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>

[saltas888]

CI is red for a reason outside this PR — develop itself is broken

python-lint is the only failing check, and it fails on a file this PR does not touch:

BLE001 Do not catch blind exception: `Exception`
  --> backend/infrahub/telemetry/utils.py:29:12

Evidence that this is not caused by this PR

• develop's own CI run is red on the same job. Run 31099670455 at b4bea5745 — the exact commit this branch is based on — has precisely one failing job: python-lint.
• This branch is 0 commits behind develop, so there is no rebase that clears it.
• Reproduced locally with this branch's change stashed — the violation is present on unmodified develop.
• This PR's whole diff is a 6-line [[tool.mypy.overrides]] deletion plus a changelog fragment. It cannot affect a ruff rule.

Root cause

release-1.11 and develop disagree on the ruff config:

Branch	BLE in ruff ignore list
release-1.11	ignored (pyproject.toml:512 — "BLE", # flake8-blind-except)
develop	not ignored — enforced

backend/infrahub/telemetry/utils.py was written on release-1.11, where BLE is ignored, so except Exception as exc: linted clean there. PR #10143 (release-1.11 → develop, merged today 12:01 UTC) carried that code into a branch that enforces BLE001, and develop went red.

Blast radius

Every PR based on post-merge develop inherits this. Other open PRs (#10147, #10144, #10141, #10137) still show python-lint green only because their last runs predate the 12:01 merge — they will go red on their next run. This PR is simply the first to be tested against post-merge develop.

Not fixing it here

The fix is a policy call that belongs on develop in its own PR, not inside an unrelated tech-debt change — either narrow the exception in safe_metric, add a scoped # noqa: BLE001, or reconcile the BLE ignore between release-1.11 and develop so the branches stop disagreeing. Escalated to a human on INBOX-30.

This PR's own verification is green: full mypy (1609 files), backend.test-unit (2233 passed), backend.validate-generated (no drift), uv lock --check.

🤖 platform-health-agent reconcile pass

[ogenstad]

This needs to be rebased and the CI should be fine.

[saltas888]

@ogenstad you were right — rebased, and develop is no longer the blocker.

When I escalated at 13:03 UTC the branch was 0 commits behind b4bea5745, so a rebase would have been a no-op at that moment — which is why the earlier pass skipped it. What changed since is that #10147 (pog-fix-develop, commit c61407da) landed the actual fix, adding # noqa: BLE001 to the degradation boundary in safe_metric. Rebasing onto 34f47cf5a picks that up, so the advice was correct as of the time you gave it.

Verified locally on the rebased branch using the exact commands CI's python-lint job runs:

• uv run ruff check . --exclude python_sdk → All checks passed
• uv run ruff format --check --exclude python_sdk . → 2331 files already formatted
• uv run ty check . → All checks passed
• uv run mypy --show-error-codes backend → no issues in 1609 files

Also fixed a second, unrelated point raised by the cubic review: the changelog fragment was missing towncrier's + orphan prefix (orphan_prefix = "+" at pyproject.toml:1207; every existing fragment carries it). Without it towncrier would have read mypy-untyped-def-core-node-base as an issue reference and rendered a bogus link. Renamed to +mypy-untyped-def-core-node-base.housekeeping.md as its own commit.

One note that may be worth a separate ticket: this failure was invisible to the local pre-push gate. invoke backend.lint runs ruff check --diff, which reports only fixable rewrites and exits 0 on an unfixable violation like BLE001, whereas CI runs a plain ruff check. So backend.lint can pass locally while python-lint fails in CI. Happy to file that if it isn't already known.

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks

---

_{Comparing pha/INBOX-30 (a6c76a1) with develop (37daa7d)}

[saltas888]

🤖 platform-health-agent — reconcile pass (CI red).

All 4 failures share one root cause, and it is not this PR. Every failing job died at stack startup, not in a test assertion:

docker compose --project-name infrahub-test-<id> up --wait  → exit 1
dependency failed to start: container infrahub-test-<id>-message-queue-1 is unhealthy

backend-docker-integration and all three Playwright jobs hit the identical message-queue healthcheck failure, which is why every integration_docker test reports ERROR at setup rather than a failure.

Evidence that it is external to this branch:

• develop's own run on 34f47cf5a — the exact commit this branch is based on — failed the same way (E2E-testing-playwright, E2E-testing-pytest-playwright (branches_repo), (foundation)), with 10 occurrences of the same message-queue-1 is unhealthy line.
• This branch is 0 commits behind develop, so there is no staleness to rebase away.
• The diff is a [[tool.mypy.overrides]] deletion plus a changelog fragment rename — no runtime surface that could affect container health.
• Onset is recent: the earlier develop run on b4bea5745 (12:01) failed for an unrelated reason with zero occurrences of this error; the run on 39ea93492 (10:19) passed. Both occurrences of this failure are from 13:29 onward.

Action taken: re-ran only the failed jobs — no push, no branch change. That is the appropriate remedy for a container healthcheck failure and distinguishes a flake from a systemic break.

If the re-run reproduces the same message-queue-1 is unhealthy, it is a develop-wide CI problem rather than anything fixable from this PR, and the next reconcile pass will escalate it on INBOX-30 for a human rather than retrying further.

Thanks for the + towncrier orphan prefix fixup in aa46964 — I missed that convention on the fragment filename.

[saltas888]

🤖 platform-health-agent — reconcile pass (CI red). Escalating to a human; no code change pushed.

@ogenstad thanks for the approval. The rebase you called for did fix the python-lint blocker. What's left is a single red check that isn't this PR's doing.

backend-docker-integration has now failed twice, for two different infrastructure reasons — neither a test failure:

Attempt	Time (UTC)	Failure
1	15:06	exit code 137 (SIGKILL/OOM) on ci-runner-huge02-ghrunner0, ~4.5 min in, during test_add_section_repo. 64 tests collected, no assertion failure, no traceback; job timeout is 45 min so it wasn't a timeout.
3	16:02	I re-ran just the failed job. It was never assigned a runner — cancelled after 3 min with runner_name empty and zero steps executed. The huge-runners pool had no capacity.

Why it isn't this PR: the entire diff vs develop is two files — deleting a [[tool.mypy.overrides]] block from pyproject.toml and adding one changelog fragment. mypy doesn't run in this job, and neither change can affect container memory or runner scheduling. The same job also passed on 6 of 6 other recent runs that executed it (including develop and stable), so the job isn't broadly broken.

Current state: 43 of 44 checks pass, approved, branch rebased onto 34f47cf5a and 0 commits behind.

Your call: re-run backend-docker-integration once the runner pool has capacity (most likely all it needs), or merge on the existing approval. I won't merge either way, and I've deliberately pushed nothing — there's nothing in the diff to fix and a speculative commit to nudge CI would just add noise.

Separately, and only as an observation: this job runs the whole backend/tests/integration_docker/ suite in one job at PYTEST_XDIST_WORKER_COUNT=1 on shared self-hosted runners, so an OOM there takes down an otherwise-green PR with no actionable signal. Not filing anything for it — just flagging.

[saltas888]

🤖 platform-health-agent — reconcile pass. Re-ran the failed job; nothing pushed.

Correcting one detail in my previous comment: of the two backend-docker-integration failures, only one was a real execution.

Attempt	Time (UTC)	What actually happened
1	15:06	Genuine failure — exit 137 (OOM), no assertion failure or traceback
3	16:02	Never ran — no runner assigned, cancelled after 3 min with zero steps executed

Attempt 3 wasn't a test result, so treating it as a second failure overstated the case. Meanwhile the same job executed successfully on two other runs today (14:18–14:38 and 14:59–15:20), so the huge-runners pool does have intermittent capacity — the 16:02 cancellation was a scheduling gap, not a broken job.

That makes a re-run the right remedy rather than a further escalation, so I've triggered one (queued at 17:02, runner assigned). No code change, no push, no branch change — the diff is still just the [[tool.mypy.overrides]] deletion plus the changelog fragment.

@ogenstad your approval still stands and I won't merge. If this run comes back green the PR is yours to merge; if it OOMs again at the same place, that's a real capacity problem with running the whole integration_docker suite in one job and I'll escalate it as its own item rather than retrying a fourth time.

[saltas888]

🤖 platform-health-agent — reconcile pass.

CI on ab15126f was red, but not from anything in the diff. Every job in all three failing workflows (CI, Keyword Scanner, Pull Request Labeler) ended cancelled, not failure — frontend-lint, Detect which file has changed and prepare-environment / prepare were all killed at exactly 18:33:07Z after ~16 minutes of runtime, and the remaining 30+ jobs were then skipped. No test, lint or validation step actually reported a failure.

That is an external cancellation, not a self-inflicted one: ci.yml sets cancel-in-progress: true on ${{ github.workflow }}-${{ github.ref }}, but no newer run exists on this ref to have superseded it. The same tree passed everything at aa46964, and ab15126f only deletes the changelog fragment.

Action taken: re-ran the three failed runs (no code change, nothing pushed). They are queued now.

For the record, this branch is 0 commits behind develop, so staleness wasn't a factor and no rebase was performed. Both review threads are addressed — the orphan-prefix fix landed in aa46964, and the changelog fragment is gone as of ab15126f, leaving the PR as exactly the 6-line [[tool.mypy.overrides]] deletion.

If the reruns get cancelled the same way again, that points at Actions infrastructure rather than this PR, and I'll escalate for a human rather than keep retrying.

[saltas888]

🤖 platform-health-agent — reconcile pass. Escalating to a human and standing down; nothing pushed, and I will not re-run CI again.

The red checks are an Actions infrastructure problem, not this PR. The evidence is now conclusive, so I'm stopping rather than triggering a third re-run.

Every red check is cancelled, not failure — all at exactly 15m00s.

Job	Last green run (aa469642, 14:04Z)	Now (ab15126f)
markdown-lint	success — 13s	cancelled at 15m03s
yaml-lint	success — 32s	cancelled at 15m03s
python-lint	success — 37s	cancelled at 15m03s
frontend-lint	success — 60s	cancelled at 15m04s

Also cancelled at the same 15-minute mark: triage, scan, infrahub-testcontainers-uv-check / uv_check. Started 19:32:28–19:33:02Z, killed 19:47:31–19:48:03Z — a uniform 15m00s ±3s kill spanning three unrelated workflows (CI, Keyword Scanner, Pull Request Labeler).

A 13-second markdown lint does not become a 15-minute hang because of a 6-line pyproject.toml deletion. These jobs are hanging before they do any work and hitting a cancellation ceiling.

What I checked and ruled out

• Staleness/rebase — branch is 0 commits behind develop (34f47cf5a); a rebase would be a no-op.
• The diff — unchanged and minimal: pyproject.toml | 6 ------. Nothing in it can affect yaml/markdown/frontend linting.
• Re-running — already tried twice. Both attempts were killed identically (18:33:07Z, then 19:47Z). That is the definition of thrash, so I'm not doing it a third time.
• Still stuck — the CI and Keyword Scanner runs have sat in queued since 18:16:53Z.

What a human needs to do: this needs someone with Actions/runner visibility — check runner-fleet capacity or a stuck queue for opsmill/infrahub, then re-run once it's healthy. The PR itself is approved (@ogenstad, 14:20Z) and ready to merge the moment CI can actually execute.

Card INBOX-30 flagged pha-needs-human. The agent will keep watching this PR but will take no further action on it.

[saltas888]

🤖 Automated reconcile pass — the red CI on this PR is not caused by this PR. No code pushed; the diff is unchanged (pyproject.toml | 6 ------).

The two genuine failures, both transient:

• backend-tests-integration — 4 failed / 482 passed. Root cause is a Neo4j Neo.TransientError.Transaction.DeadlockDetected raised at setup of test_profile_lifecycle.py::test_step_15_schema_update_add_attributes during a schema migration on xdist worker gw3; test_step_16 cascaded from it. Neo4j itself classifies this error class as Transient.
• E2E-testing-playwright — 1 failed: branch-selector "a name that does not exists" (element(s) not found). The same job also fails on develop head 34f47cf5a but on a different test (object-groups.spec.ts), and that run separately lost E2E-testing-pytest-playwright (branches_repo) to an unhealthy compose container. A different test failing each run is a suite flake, not a regression.

Why this diff can't be responsible: it deletes one [[tool.mypy.overrides]] block. That block is read only by mypy and has no runtime effect, so it cannot influence Neo4j lock ordering or a Playwright locator. Separately, develop is itself red right now — its last two CI runs failed, including python-lint on b4bea5745 from a pre-existing BLE001 in backend/infrahub/telemetry/utils.py that is outside this diff.

Also present and not diagnosed: 8 jobs were cancelled at exactly 15m00s (±3s) — including backend-tests-unit on 3.12/3.13/3.14, a suite that completes in ~38s locally — and the Keyword Scanner run has sat queued for 2h+. That looks like an Actions/runner issue rather than anything in this branch, and it needs someone with runner visibility.

Action: re-ran the failed jobs once (the fleet is idle, and re-running is the standard answer to identified flakes). Staleness was checked first per the CI playbook — the branch is 0 commits behind develop, so a rebase would be a no-op.

Tracked in INBOX-30, which stays flagged for a human on the runner question. This bot never merges.

[saltas888]

🤖 platform-health-agent — correcting my earlier comments, and then I'll stop commenting here.

CI is not failing on this PR anymore — it isn't running at all, repo-wide.

The three workflows on ab15126f have been queued since 18:16Z (~3h45m) with no runner assigned. Across the whole repo, no workflow run has executed real work since 18:17Z — the only completions in that window are skipped no-ops. It isn't this branch: gma-clone-repo-default-branch has a CI run queued since 14:58Z, ~7 hours.

I'm not re-running anything: that would enqueue into a queue nobody is servicing and forfeit the current position.

For whoever picks this up: the full CI run on the previous head aa469642 finished ✅ success at 17:26Z, and the only change since is deleting the changelog fragment @ogenstad asked for (+0/-1, one file, no source). So this tree is green on the last CI that actually executed. The PR is approved with both threads resolved — it needs either a human merge or someone looking at Actions runner capacity.

[ogenstad]

There must have been some GitHub issue yesterday, now the pipeline is green but most of the jobs have not run. Not sure if there's a way to retrigger it in the current state. A rebase with the latest changes from develop should do it.

[saltas888]

@ogenstad Rebased onto latest develop (was 48 behind) and force-pushed — ab15126f → 274c66b1. That unstuck it: Keyword Scanner and Pull Request Labeler both went green on the new SHA within a minute, and CI is queued and moving, versus the runs on the old SHA that sat queued for ~13h.

Re-ran uv run mypy --show-error-codes backend after the rebase — clean across 1610 files, so the claim still holds against the 48 new commits. Net diff is unchanged: pyproject.toml | 6 ------.

Your approval predates the force-push, so it may need re-confirming before merge.

[saltas888]

Re-verified after the develop merge (a6c76a1e): uv run mypy --show-error-codes backend → no issues in 1610 source files. The merge didn't reintroduce the override, and the effective diff is now exactly the 6-line [[tool.mypy.overrides]] deletion.

CI on the merge commit: 36 passed, 15 skipped, 4 still running (docker-integration, tests-component, tests-integration, E2E-playwright) — nothing failing; the UNSTABLE merge state is just those pending jobs.

Taking the changelog point: the fragment was both misnamed (this repo sets towncrier orphan_prefix = "+", so issue-less fragments need the + prefix) and unwarranted in the first place — a change that touches no source code doesn't need a user-facing entry. I added it reflexively for convention rather than because it belonged. Thanks for catching both.

Ready for merge whenever CI settles — leaving that to a human.