fix: correct type annotations and improve CI cache invalidation

[ajbozarth]

Misc PR

Type of PR

• Bug Fix
• New Feature
• Documentation
• Other

Description

• Link to Issue:

Fix MyPy Type Errors and CI Cache Invalidation

Problem

MyPy type errors were occurring locally but not caught in CI:

mellea/formatters/granite/retrievers/elasticsearch.py:25: error: Argument 2 to "Elasticsearch" has incompatible type "**dict[str, dict[str, int]]"

Root Cause

1. Type Error: Incorrect **kwargs annotation (dict[str, int] instead of Any) in elasticsearch.py
2. CI Cache Issue: Pre-commit cache key didn't include uv.lock, so MyPy used stale cached results when dependencies changed

The bug was introduced when PR #571 (code) and PR #570 (dependencies) were merged separately. CI never re-checked the files with the new type information because the cache wasn't invalidated.

Changes

Type Fix

• Fixed **kwargs: dict[str, int] → **kwargs: Any in elasticsearch.py

CI Fix

• Updated pre-commit cache key to include uv.lock hash
• Ensures MyPy re-checks files whenever dependencies change

Testing

✅ pre-commit run --all-files passes locally
✅ All MyPy type checks pass

Impact

Prevents future type errors from being masked by stale CI cache when dependencies are added or updated.

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code as added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

[github-actions]

The PR description has been updated. Please fill out the template for your PR to be reviewed.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert|release)(?:\(.+\))?:

ci failures

[nrfulton]

thanks for the quick investigation.

CI never re-checked the files with the new type information because the cache wasn't invalidated.

Is this a bug in our ci/cd or does this fall into the category of stuff we'd rather handle with nightlies so that the github actions ci/cd has fast-as-possible turn-around?

[ajbozarth]

Is this a bug in our ci/cd or does this fall into the category of stuff we'd rather handle with nightlies so that the github actions ci/cd has fast-as-possible turn-around?

I would consider it a bug, but it's up to interpretation. I think the current cache hashing was overzealous and had the potential to hid issues caused by dependency version updates.

Though this fix can end up slowing down the CI it is a drop in the bucket compared to out tests

[nrfulton]

I think some slow-down is fine - mypy breakage is deeply disruptive to all downstream work. IMO the balance of concerns here justified invalidation.