Skip to content

Conversation

@HardMax71
Copy link
Owner

@HardMax71 HardMax71 commented Dec 22, 2025

Summary by CodeRabbit

  • Chores
    • Increased type-checking strictness in CI.
    • Broad improvements to type annotations across backend services, including database abstractions and collection/client typings.
    • Enhanced tracing typings and safer generics for decorators.
    • Added/clarified generic types in utility and seeding scripts for more precise static checks and maintainability.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Dec 22, 2025

Important

Review skipped

Too many files!

40 files out of 190 files are above the max files limit of 150.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

📝 Walkthrough

Walkthrough

Adds stricter MyPy checking and broadens typing refinements: advanced generics in tracing utilities, introduction of Mongo document type aliases and DB/Collection/Cursor abstractions, and widespread replacement of motor driver types with the new database-context types and parameterized motor generics for local client usage.

Changes

Cohort / File(s) Summary
CI workflow
\.github/workflows/mypy.yml
Enabled stricter static type checking by adding the --strict flag to the MyPy invocation.
Tracing utilities
backend/app/core/tracing/utils.py
Introduced ParamSpec/TypeVar generics (P, R) and tightened callable typings for trace_method; replaced Dict[...] hints with lowercase dict[...] and refined several span/context helper signatures.
Database context & motor generics
backend/app/core/database_context.py, backend/scripts/seed_users.py
Added MongoDocument = dict[str, Any], parameterized DBClient/Database/Collection/Cursor aliases (e.g., AsyncIOMotorClient[MongoDocument], Database, Collection, Cursor), and applied dict[str, Any] typing for seed script motor usage.
Provider wiring / DI
backend/app/core/providers.py, backend/app/core/dishka_lifespan.py
Updated provider and lifespan signatures to use the new Database abstraction instead of motor-specific AsyncIOMotorDatabase; adjusted imports and downstream wiring accordingly.
Repositories (DB typing changes)
backend/app/db/repositories/*, backend/app/db/repositories/admin/*
backend/app/db/repositories/admin/admin_*_repository.py, .../dlq_repository.py, .../event_repository.py, .../execution_repository.py, .../notification_repository.py, .../replay_repository.py, .../resource_allocation_repository.py, .../saga_repository.py, .../saved_script_repository.py, .../sse_repository.py, .../user_repository.py, .../user_settings_repository.py
Replaced motor-specific parameter and collection type hints (AsyncIOMotorDatabase, AsyncIOMotorCollection, etc.) with project-local Database, Collection (and Cursor where applicable). Constructors and public attribute annotations updated; behavior unchanged.
Event store & schema manager
backend/app/events/event_store.py, backend/app/db/schema/schema_manager.py
Switched signatures and internal type annotations to use Database, Collection, and Cursor aliases; updated create_event_store and cursor deserialization typing.
DLQ manager & DLQ worker wiring
backend/app/dlq/manager.py, backend/workers/dlq_processor.py
DLQManager and creation function updated to accept/return Database/Collection types; worker files updated local annotations to use DBClient/Database.
Services & workers (local client typing)
backend/app/services/coordinator/coordinator.py, backend/app/services/k8s_worker/worker.py, backend/workers/run_event_replay.py, backend/workers/run_saga_orchestrator.py, backend/app/services/k8s_worker/*
Local variable and constructor annotations changed to use DBClient/Database types instead of concrete AsyncIOMotorClient/AsyncIOMotorDatabase. Instantiation still uses AsyncIOMotorClient(...); runtime unchanged.
Other service wiring
backend/app/dlq/manager.py, backend/app/events/event_store.py, backend/app/services/*
Miscellaneous import and type-hint updates across services to align with new database-context types; no functional changes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 21.05% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title accurately describes the main change: introducing mypy strict mode type checking across the codebase, which is reflected in the workflow modifications and extensive type annotation updates throughout the project.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov-commenter
Copy link

codecov-commenter commented Dec 22, 2025

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 67.62590% with 315 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
backend/app/core/metrics/notifications.py 28.57% 20 Missing ⚠️
backend/app/core/metrics/replay.py 4.76% 20 Missing ⚠️
backend/app/core/metrics/security.py 20.83% 19 Missing ⚠️
backend/app/core/metrics/kubernetes.py 5.88% 16 Missing ⚠️
backend/app/services/coordinator/coordinator.py 48.00% 13 Missing ⚠️
backend/app/core/metrics/context.py 53.84% 12 Missing ⚠️
backend/app/core/startup.py 7.69% 12 Missing ⚠️
backend/app/events/consumer_group_monitor.py 20.00% 10 Missing and 2 partials ⚠️
...ackend/app/services/event_replay/replay_service.py 62.06% 11 Missing ⚠️
backend/app/core/metrics/health.py 0.00% 10 Missing ⚠️
... and 49 more
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.
Flag Coverage Δ
backend 67.10% <67.62%> (+0.31%) ⬆️
frontend ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
backend/app/api/dependencies.py 100.00% <100.00%> (ø)
backend/app/api/routes/admin/users.py 83.51% <100.00%> (+0.56%) ⬆️
backend/app/api/routes/auth.py 92.20% <100.00%> (ø)
backend/app/api/routes/dlq.py 79.59% <100.00%> (+0.42%) ⬆️
backend/app/api/routes/grafana_alerts.py 100.00% <100.00%> (ø)
backend/app/api/routes/health.py 100.00% <100.00%> (ø)
backend/app/api/routes/notifications.py 95.65% <100.00%> (+0.09%) ⬆️
backend/app/api/routes/replay.py 83.72% <100.00%> (ø)
backend/app/api/routes/saga.py 86.36% <100.00%> (ø)
backend/app/api/routes/saved_scripts.py 100.00% <100.00%> (ø)
... and 164 more

... and 31 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (7)
backend/app/db/schema/schema_manager.py (1)

110-132: Fix missing type parameters for dict return type.

MyPy strict mode requires explicit type parameters for generic types. The return type annotation is missing, causing the pipeline failure.

🔎 Proposed fix
-    @staticmethod
-    def _event_json_schema() -> dict:
+    @staticmethod
+    def _event_json_schema() -> dict[str, Any]:
backend/workers/dlq_processor.py (1)

1-12: Fix import organization to resolve Ruff linting failure.

The imports need to be sorted according to the project convention to resolve the I001 linting error.

🔎 Proposed fix

Organize imports into groups: stdlib, third-party, local. Run:

ruff check --select I --fix backend/workers/dlq_processor.py
backend/app/db/repositories/execution_repository.py (3)

58-58: Fix type incompatibility for execution_id parameter.

MyPy strict mode correctly identifies that document.get("execution_id") returns Any | None, but the DomainExecution constructor expects str. This needs explicit handling.

🔎 Proposed fix
         sv = document.get("status")
         return DomainExecution(
-            execution_id=document.get("execution_id"),
+            execution_id=str(document.get("execution_id", "")),
             script=document.get("script", ""),

Alternatively, if execution_id is truly required:

execution_id = document.get("execution_id")
if not execution_id:
    raise ValueError(f"Missing execution_id in document")
return DomainExecution(
    execution_id=str(execution_id),
    ...
)

68-68: Fix type incompatibility for from_dict argument.

The document.get("resource_usage") can return Any | None, but ResourceUsageDomain.from_dict expects dict[str, Any]. The None check on Line 69 is correct, but mypy needs the type to be narrowed before the call.

🔎 Proposed fix
             resource_usage=(
-                ResourceUsageDomain.from_dict(document.get("resource_usage"))
-                if document.get("resource_usage") is not None
+                ResourceUsageDomain.from_dict(resource_usage)
+                if (resource_usage := document.get("resource_usage")) is not None
+                and isinstance(resource_usage, dict)
                 else None
             ),

Or more explicitly:

resource_usage_data = document.get("resource_usage")
resource_usage = (
    ResourceUsageDomain.from_dict(resource_usage_data)
    if resource_usage_data is not None and isinstance(resource_usage_data, dict)
    else None
)

77-77: Add type parameters to generic dict types.

MyPy strict mode requires type parameters for generic types. Specify the key and value types for these dict parameters.

🔎 Proposed fix
-    async def update_execution(self, execution_id: str, update_data: dict) -> bool:
+    async def update_execution(self, execution_id: str, update_data: dict[str, object]) -> bool:

-    async def get_executions(
-            self,
-            query: dict,
+    async def get_executions(
+            self,
+            query: dict[str, object],

-    async def count_executions(self, query: dict) -> int:
+    async def count_executions(self, query: dict[str, object]) -> int:

Also applies to: 126-126, 163-163

backend/app/dlq/manager.py (1)

51-53: Add type parameters to asyncio.Task generic types.

MyPy strict mode requires type parameters for generic Task types. Specify the return type for these task attributes.

🔎 Proposed fix
         self._running = False
-        self._process_task: asyncio.Task | None = None
-        self._monitor_task: asyncio.Task | None = None
+        self._process_task: asyncio.Task[None] | None = None
+        self._monitor_task: asyncio.Task[None] | None = None
backend/app/core/providers.py (1)

128-133: Fix: Use typed ping() method instead of untyped execute_command().

The pipeline failure explicitly indicates: Call to untyped function "execute_command" in typed context [no-untyped-call]. The execute_command method lacks proper type annotations in redis-py's async stubs, causing mypy strict mode to fail.

🔎 Proposed fix
         # Test connection
-        await client.execute_command("PING")
+        await client.ping()
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3bc5f31 and af8da2a.

📒 Files selected for processing (25)
  • backend/app/core/database_context.py
  • backend/app/core/dishka_lifespan.py
  • backend/app/core/providers.py
  • backend/app/db/repositories/admin/admin_events_repository.py
  • backend/app/db/repositories/admin/admin_settings_repository.py
  • backend/app/db/repositories/admin/admin_user_repository.py
  • backend/app/db/repositories/dlq_repository.py
  • backend/app/db/repositories/event_repository.py
  • backend/app/db/repositories/execution_repository.py
  • backend/app/db/repositories/notification_repository.py
  • backend/app/db/repositories/replay_repository.py
  • backend/app/db/repositories/resource_allocation_repository.py
  • backend/app/db/repositories/saga_repository.py
  • backend/app/db/repositories/saved_script_repository.py
  • backend/app/db/repositories/sse_repository.py
  • backend/app/db/repositories/user_repository.py
  • backend/app/db/repositories/user_settings_repository.py
  • backend/app/db/schema/schema_manager.py
  • backend/app/dlq/manager.py
  • backend/app/events/event_store.py
  • backend/app/services/coordinator/coordinator.py
  • backend/app/services/k8s_worker/worker.py
  • backend/workers/dlq_processor.py
  • backend/workers/run_event_replay.py
  • backend/workers/run_saga_orchestrator.py
✅ Files skipped from review due to trivial changes (1)
  • backend/app/db/repositories/admin/admin_settings_repository.py
🧰 Additional context used
🧬 Code graph analysis (14)
backend/app/dlq/manager.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/saga_repository.py (2)
backend/tests/conftest.py (2)
  • app (130-138)
  • db (178-180)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/replay_repository.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/core/dishka_lifespan.py (2)
backend/tests/conftest.py (1)
  • app (130-138)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/sse_repository.py (2)
backend/tests/conftest.py (2)
  • app (130-138)
  • db (178-180)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/user_settings_repository.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/user_repository.py (1)
backend/tests/conftest.py (2)
  • app (130-138)
  • db (178-180)
backend/app/db/repositories/event_repository.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/saved_script_repository.py (2)
backend/tests/conftest.py (2)
  • app (130-138)
  • db (178-180)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/workers/dlq_processor.py (1)
backend/app/core/database_context.py (6)
  • db_name (73-75)
  • db_name (156-157)
  • db_name (209-210)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/dlq_repository.py (1)
backend/tests/conftest.py (2)
  • app (130-138)
  • db (178-180)
backend/app/db/repositories/resource_allocation_repository.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/services/k8s_worker/worker.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
backend/app/db/repositories/notification_repository.py (1)
backend/app/core/database_context.py (3)
  • database (68-70)
  • database (150-153)
  • database (205-206)
🪛 GitHub Actions: MyPy Type Checking
backend/app/db/schema/schema_manager.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).


[error] 111-111: Missing type parameters for generic type "dict" [type-arg].

backend/workers/run_event_replay.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/dlq/manager.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).


[error] 52-52: Missing type parameters for generic type "Task" [type-arg].


[error] 53-53: Missing type parameters for generic type "Task" [type-arg].

backend/app/db/repositories/saga_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/replay_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/workers/run_saga_orchestrator.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/execution_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).


[error] 58-58: Argument "execution_id" to "DomainExecution" has incompatible type "Any | None"; expected "str" [arg-type].


[error] 68-68: Argument 1 to "from_dict" of "ResourceUsageDomain" has incompatible type "Any | None"; expected "dict[str, Any]" [arg-type].


[error] 77-77: Missing type parameters for generic type "dict" [type-arg].


[error] 126-126: Missing type parameters for generic type "dict" [type-arg].


[error] 163-163: Missing type parameters for generic type "dict" [type-arg].

backend/app/core/dishka_lifespan.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/sse_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/user_settings_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/user_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/core/database_context.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/event_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/saved_script_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/events/event_store.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/admin/admin_events_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/workers/dlq_processor.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/dlq_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/resource_allocation_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/core/providers.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).


[error] 130-130: Call to untyped function "execute_command" in typed context [no-untyped-call].

backend/app/services/coordinator/coordinator.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/services/k8s_worker/worker.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/notification_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

backend/app/db/repositories/admin/admin_user_repository.py

[error] 1-1: CI step failed: 'mypy --config-file pyproject.toml --strict .' reported errors (exit code 1).

🪛 GitHub Actions: Ruff Linting
backend/workers/run_event_replay.py

[error] 1-1: I001: Import block is un-sorted or un-formatted. Organize imports.

backend/workers/run_saga_orchestrator.py

[error] 1-1: I001: Import block is un-sorted or un-formatted. Organize imports.

backend/workers/dlq_processor.py

[error] 1-1: I001: Import block is un-sorted or un-formatted. Organize imports.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Integration Tests
🔇 Additional comments (28)
backend/app/core/database_context.py (1)

111-122: LGTM! Type-safe client instantiation with explicit event loop binding.

The explicit type annotation and event loop binding at line 121 help prevent common asyncio pitfalls in multi-threaded environments.

backend/app/db/schema/schema_manager.py (1)

8-18: Migration to Database abstraction looks good.

The constructor signature change maintains backward compatibility at the runtime level while improving type safety.

backend/workers/run_event_replay.py (1)

40-44: Type annotation migration looks good.

The DBClient type alias correctly replaces AsyncIOMotorClient while maintaining runtime behavior.

backend/workers/dlq_processor.py (1)

101-109: Type annotations correctly migrated to Database abstractions.

Both DBClient and Database type aliases are properly applied, maintaining runtime behavior while improving type safety.

backend/app/db/repositories/saved_script_repository.py (1)

1-15: Clean migration to Database and Collection abstractions.

The repository correctly adopts the new type aliases, maintaining consistency with the broader migration effort across the codebase.

backend/app/services/coordinator/coordinator.py (1)

11-11: DBClient type alias correctly applied.

The type annotation properly uses the new abstraction while maintaining the existing instantiation pattern.

Also applies to: 553-559

backend/workers/run_saga_orchestrator.py (1)

31-37: Type annotation correctly updated to DBClient.

The DBClient type alias properly replaces AsyncIOMotorClient while preserving runtime behavior.

backend/app/core/dishka_lifespan.py (1)

8-8: Database abstraction properly integrated into DI configuration.

The migration from AsyncIOMotorDatabase to the Database type alias in the dependency injection container is correct and complete. The Dishka container correctly retrieves dependencies by calling .get(SomeType), and the Database provider is properly configured in providers.py (lines 108-109) to supply the Database type. All repositories and services that depend on Database resolve correctly through the DI system.

backend/app/db/repositories/event_repository.py (1)

8-8: LGTM! Clean migration to database context abstractions.

The migration from Motor-specific types to the internal Database and Collection abstractions is well-executed and consistent. This aligns with the PR's goal of introducing stricter type checking.

Also applies to: 28-31

backend/app/db/repositories/user_repository.py (1)

5-5: LGTM! Consistent type abstraction migration.

The changes properly adopt the project's Database and Collection abstractions, maintaining consistency with the broader codebase refactoring.

Also applies to: 15-17

backend/app/db/repositories/resource_allocation_repository.py (1)

3-3: LGTM! Type abstractions properly applied.

The migration to Database and Collection types is clean and follows the established pattern across the codebase.

Also applies to: 10-12

backend/app/db/repositories/execution_repository.py (1)

3-3: LGTM! Database abstraction migration is clean.

The migration to Database and Collection types is properly implemented and consistent with the codebase-wide refactoring.

Also applies to: 11-14

backend/app/dlq/manager.py (1)

9-9: LGTM! Database abstraction adoption is correct.

The migration to Database and Collection types, including the updated factory function signature, is clean and aligns with the codebase-wide refactoring.

Also applies to: 33-33, 49-49, 398-403

backend/app/db/repositories/dlq_repository.py (1)

4-4: LGTM! Proper database abstraction migration.

The changes correctly adopt the Database and Collection abstractions, maintaining consistency with the project-wide type refactoring.

Also applies to: 26-28

backend/app/db/repositories/sse_repository.py (1)

1-1: LGTM! Database abstraction properly implemented.

The migration to Database and Collection types is clean and consistent, correctly handling multiple collection attributes.

Also applies to: 9-12

backend/app/db/repositories/saga_repository.py (1)

5-5: LGTM! Clean database abstraction migration.

The migration to Database and Collection types is properly implemented, correctly handling multiple collection attributes and maintaining the repository pattern.

Also applies to: 13-24

backend/app/db/repositories/replay_repository.py (1)

14-17: LGTM! Consistent use of Database abstraction.

The constructor and collection initialization correctly use the new Database and Collection type abstractions, with consistent use of get_collection() throughout the file.

backend/app/db/repositories/user_settings_repository.py (1)

18-23: LGTM! Consistent migration to Database abstraction.

The repository correctly adopts the Database and Collection type abstractions with consistent use of get_collection().

backend/app/services/k8s_worker/worker.py (2)

59-72: LGTM! Correct use of Database abstraction in worker.

The constructor properly accepts Database and assigns it to self._db with the correct type annotation.


560-566: Type annotation correctly uses DBClient alias.

The db_client: DBClient annotation paired with AsyncIOMotorClient instantiation correctly separates the type abstraction from the concrete implementation.

backend/app/db/repositories/admin/admin_events_repository.py (1)

46-58: LGTM! Comprehensive migration to Database abstraction.

All collection bindings correctly use get_collection() with the new Collection type, maintaining consistency across the repository.

backend/app/events/event_store.py (2)

20-34: LGTM with note on collection access pattern.

The db[collection_name] subscript notation is valid for MongoDB databases. Verify the Database type alias includes __getitem__ support in its type definition to satisfy mypy strict mode.


310-311: Good: Cursor type correctly applied to internal method.

The _deserialize_cursor method now uses the abstract Cursor type, maintaining consistency with the broader type abstraction.

backend/app/db/repositories/admin/admin_user_repository.py (1)

19-31: LGTM! Clean migration to Database abstraction.

All collection bindings use get_collection() consistently with proper Collection type annotations.

backend/app/core/providers.py (3)

107-109: LGTM! Database abstraction correctly returned from connection.

The get_database method properly returns the Database type from the connection abstraction.


176-183: LGTM! DLQ manager provider correctly uses Database type.


210-221: LGTM! Consistent Database type usage across all repository providers.

All repository provider methods correctly accept Database and pass it to repository constructors.

Also applies to: 332-337, 368-369, 380-381, 384-385, 418-419, 429-431, 441-442, 445-446, 449-450, 485-486, 489-490, 493-494, 497-498, 501-502, 626-627

backend/app/db/repositories/notification_repository.py (1)

19-24: LGTM on changed lines.

The initialization correctly uses get_collection(). The code also uses direct attribute access (self.db.users, self.db.executions) elsewhere, which is idiomatic and fully supported by Motor's AsyncIOMotorDatabase—both patterns are equivalent and type-safe.

Likely an incorrect or invalid review comment.

@sonarqubecloud
Copy link

@HardMax71 HardMax71 merged commit 4c419f7 into main Dec 23, 2025
13 checks passed
@HardMax71 HardMax71 deleted the mypy-strict branch December 23, 2025 22:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants