chore(deps): update dependency pyright to >=1.1.407,<1.1.408

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
pyright	>=1.1.406,<1.1.407 -> >=1.1.407,<1.1.408

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

RobertCraigie/pyright-python (pyright)

v1.1.407

Compare Source

---

Configuration

📅 Schedule: Branch creation - "before 2am every weekday" in timezone Europe/Berlin, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Claude finished @renovate[bot]'s task —— View job

---

Pyright Dependency Update Review - ⚠️ BLOCKING ISSUES FOUND

Executive Summary

DO NOT MERGE - This PR updates Pyright from 1.1.406 to 1.1.407, which introduces 301 type checking errors due to a known regression in Pyright 1.1.407 (microsoft/pyright#11060).

The comment in pyproject.toml line 160 already warns about this regression, but Renovate updated TO the broken version instead of avoiding it.

---

Critical Findings

🚨 BLOCKING: Type Checking Failures (301 errors)

Location: Multiple GUI files across the SDK
Issue: Pyright 1.1.407 has a regression with dataclass decorators

Reproduction:

uv sync --all-extras
uv run pyright src/aignostics
# Output: 301 errors, 0 warnings, 0 informations

Root Cause:

• The SDK uses NiceGUI's @binding.bindable_dataclass decorator extensively in GUI modules
• This decorator transforms classes into dataclasses with bindable fields
• Pyright 1.1.407 incorrectly flags attribute access as errors (reportAttributeAccessIssue)
• Same regression affects Pydantic dataclasses and similar patterns

Sample Errors:

src/aignostics/application/_gui/_page_application_describe.py:111:16
  Cannot assign to attribute "application_id" for class "DataclassInstance"
  Attribute "application_id" is unknown (reportAttributeAccessIssue)

src/aignostics/dataset/_gui.py:226:39
  Cannot assign to attribute "destination_open_button" for class "DataclassInstance"
  Attribute "destination_open_button" is unknown (reportAttributeAccessIssue)

Affected Files (sample):

• src/aignostics/application/_gui/_page_application_describe.py
• src/aignostics/application/_gui/_page_application_run.py
• src/aignostics/dataset/_gui.py
• src/aignostics/bucket/_gui.py
• All GUI modules using @binding.bindable_dataclass

CI/CD Impact:

• According to CLAUDE.md, dual type checking is enforced (MyPy strict + PyRight basic)
• BOTH type checkers must pass in CI/CD
• make lint includes PyRight check
• This PR will fail the lint stage in CI/CD

---

Upstream Issue Status

Issue: microsoft/pyright#11060

• Type: Regression in 1.1.407
• Status: ✅ Fixed in upstream (PR #11084 merged)
• Fix Available: Will be in Pyright 1.1.408 or later
• Timeline: Fix committed November 2, 2025

---

Recommendations

✅ Recommended Action: Close this PR and wait for 1.1.408

# Keep current constraint until fix is released
"pyright>=1.1.406,<1.1.407", # Regression in 1.1.407, see https://github.com/microsoft/pyright/issues/11060

Alternative: Pin to 1.1.406

# Explicit pin if needed
"pyright==1.1.406",

When Pyright 1.1.408+ is available:

# Update constraint to include fixed version
"pyright>=1.1.408,<1.1.409", # Regression in 1.1.407 fixed in 1.1.408

---

Review Checklist

• ✅ Read changed files (pyproject.toml, uv.lock)
• ✅ Review pyrightconfig.json for compatibility
• ✅ Check CLAUDE.md guidance on type checking (dual checking enforced)
• ⚠️ CI/CD will fail (type checking is blocking)
• ⚠️ Local type checking fails with 301 errors
• ✅ Upstream issue confirmed and fixed

---

Testing Performed

# Environment setup
uv sync --all-extras

# Verify pyright version
uv run pyright --version
# Output: pyright 1.1.407

# Run type checking
uv run pyright src/aignostics
# Result: 301 errors, 0 warnings, 0 informations

# All errors are reportAttributeAccessIssue for bindable_dataclass decorated classes

---

Additional Context

Why the comment exists: The comment in line 160 was added precisely to prevent updating to 1.1.407:

"pyright>=1.1.406,<1.1.407", # Regression in 1.1.407, see https://github.com/microsoft/pyright/issues/11060

Renovate behavior: Renovate updated the version constraint but kept the warning comment, which creates a contradictory state.

Medical Device Impact: This is medical device software (computational pathology SDK). Type checking is critical for safety and compliance. Merging broken type checking would compromise:

• Code quality gates
• Pre-commit hooks
• CI/CD pipeline integrity
• Regulatory compliance workflows

---

Conclusion

❌ REJECT THIS PR

This dependency update introduces a known regression that breaks type checking across all GUI modules. Wait for Pyright 1.1.408 or later which includes the fix for microsoft/pyright#11060.

Next Steps:

1. Close this PR
2. Update Renovate configuration to skip 1.1.407 if not already configured
3. Wait for Renovate to create a new PR for Pyright >=1.1.408
4. The fix is already merged upstream, so 1.1.408 should be available soon

---

[github-actions]

Claude finished @renovate[bot]'s task —— View job

---

Pyright v1.1.407 Dependency Update Review - ❌ BLOCKING ISSUES FOUND

Todo List

• Read changed files (pyproject.toml, uv.lock)
• Verify Pyright version and regression status
• Run type checking to confirm current state
• Check upstream issue status
• Provide final recommendation

---

Executive Summary

❌ DO NOT MERGE - This PR updates Pyright to version 1.1.407, which contains a known regression causing 301 type checking errors across all GUI modules in the SDK.

---

Critical Findings

🚨 Type Checking Regression (BLOCKING)

Issue: Pyright 1.1.407 has a regression with dataclass decorators (microsoft/pyright#11060)

Impact: 301 errors across the codebase, all related to @binding.bindable_dataclass decorator from NiceGUI

Verification:

$ uv run pyright --version
pyright 1.1.407

$ uv run pyright src/aignostics
301 errors, 0 warnings, 0 informations

Sample Errors:

src/aignostics/application/_gui/_page_application_describe.py:112:17
  Cannot assign to attribute "application_id" for class "DataclassInstance"
  Attribute "application_id" is unknown (reportAttributeAccessIssue)

src/aignostics/dataset/_gui.py:226:39
  Cannot assign to attribute "destination_open_button" for class "DataclassInstance"
  Attribute "destination_open_button" is unknown (reportAttributeAccessIssue)

Root Cause:

• Regression introduced in Pyright 1.1.407 via PR #11018
• Affects Pydantic dataclasses and similar decorator patterns
• The SDK uses @binding.bindable_dataclass extensively in GUI modules

Affected Modules:

• All GUI modules (_gui.py files)
• Includes: application, dataset, bucket, wsi, qupath, system

---

Contradictory State in pyproject.toml

Line 161 contains a contradictory comment:

"pyright>=1.1.407,<1.1.408", # Regression in 1.1.407, see https://github.com/microsoft/pyright/issues/11060

The comment warns about the regression in 1.1.407, yet the version constraint includes 1.1.407. This should have been:

"pyright>=1.1.406,<1.1.407", # Regression in 1.1.407, see https://github.com/microsoft/pyright/issues/11060

---

Upstream Status

Issue: microsoft/pyright#11060

• Status: ✅ Fixed (PR #11084 merged November 2, 2025)
• Fix Available In: Next version after 1.1.407 (not yet released)
• Current PyPI Version: 1.1.407 (released October 24, 2025)
• Expected Fix Version: 1.1.408 (not yet published to PyPI)

---

CI/CD Impact

According to CLAUDE.md:

Type Checking (NEW in v1.0.0-beta.7 - Dual Type Checkers):

• MyPy: Strict mode enforced (make lint runs MyPy)
• PyRight: Basic mode with selective exclusions (pyrightconfig.json)
• Both type checkers must pass in CI/CD

This PR will fail the lint stage because:

1. make lint runs both MyPy and PyRight
2. PyRight currently shows 301 errors
3. CI/CD requires both type checkers to pass

---

Recommendations

✅ Immediate Action: Revert pyproject.toml change

Update line 161 from:

"pyright>=1.1.407,<1.1.408", # Regression in 1.1.407, see https://github.com/microsoft/pyright/issues/11060

To:

"pyright>=1.1.406,<1.1.407", # Regression in 1.1.407 (fixed in 1.1.408+), see https://github.com/microsoft/pyright/issues/11060

⏰ Future Action: Update when 1.1.408 is released

When Pyright 1.1.408 appears on PyPI:

"pyright>=1.1.408,<1.1.409", # Regression in 1.1.407 fixed in 1.1.408

🤖 Renovate Configuration

Consider adding to Renovate config to skip known-broken versions:

{
  "packageRules": [
    {
      "matchPackageNames": ["pyright"],
      "allowedVersions": "!1.1.407"
    }
  ]
}

---

Why This Matters for Medical Device Software

This SDK is used for computational pathology - a regulated medical device domain requiring:

• ✅ Type Safety: Critical for preventing runtime errors in medical workflows
• ✅ Regulatory Compliance: Type checking is part of quality gates
• ✅ CI/CD Integrity: Broken type checking blocks deployments

Impact of merging:

• ❌ All CI/CD builds fail at lint stage
• ❌ Developers cannot commit (pre-commit hooks include pyright)
• ❌ False positives hide real type issues
• ❌ Quality gates compromised

---

Testing Performed

# Confirmed regression exists
uv sync --all-extras
uv run pyright --version  # Output: pyright 1.1.407
uv run pyright src/aignostics  # Output: 301 errors

# Verified upstream fix merged but not yet released
# Checked PyPI - 1.1.407 is latest (no 1.1.408 yet)

---

Conclusion

❌ REJECT THIS PR

This dependency update introduces 301 type checking errors due to a known Pyright regression. The fix is merged upstream but not yet released to PyPI as version 1.1.408.

Required Actions:

1. ✅ Update pyproject.toml to exclude 1.1.407
2. ✅ Regenerate uv.lock with uv lock
3. ⏰ Wait for Pyright 1.1.408 release
4. ⏰ Create new PR when 1.1.408 is available

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

❗ There is a different number of reports uploaded between BASE (3eddfe4) and HEAD (d5a4d02). Click for more details.

HEAD has 6 uploads less than BASE

Flag	BASE (3eddfe4)	HEAD (d5a4d02)
	7	1

see 22 files with indirect coverage changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud