refactor: code formatting and minor improvements across modules

[frigini]

• Apply dotnet format to standardize code style
• Update infrastructure documentation and database scripts
• Add test infrastructure improvements
• Update Location module API clients formatting
• Update Search module DTOs and queries formatting
• Improve test base classes and utilities
• Add database role and permission scripts for Location and Search modules

Summary by CodeRabbit

• New Features

  • PostGIS-enabled database support, updated compose/dev settings, DB init & validation scripts, and CI workflow step that provides mapped DB connection strings.
  • Default no-op background job binding and safer dashboard startup checks.

• Documentation

  • Expanded Service Catalog spec and comprehensive DB/TestContainers and infrastructure docs.

• Tests

  • New E2E test types (paginated/token), integration authentication tests, and a shared JSON response helper for tests.

[frigini]

@coderabbitai review

[coderabbitai]

Warning

Rate limit exceeded

@frigini has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 23 minutes and 50 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between d5d681d and c186746.

📒 Files selected for processing (4)

• .github/actions/setup-postgres-connection/README.md (1 hunks)
• .github/actions/setup-postgres-connection/action.yml (1 hunks)
• infrastructure/test-database-init.sh (1 hunks)
• src/Shared/Jobs/HangfireExtensions.cs (2 hunks)

Walkthrough

Adds PostGIS-backed PostgreSQL to CI and local compose, wires a new Setup PostgreSQL connection action to export a connection-string that is mapped into multiple .NET ConnectionStrings env vars, adds DB init/validation scripts and search/location schema/role SQL, expands roadmap and test infra docs, registers a NoOp background-job service and refactors Hangfire dashboard wiring, plus many small formatting fixes.

Changes

Cohort / File(s)	Summary
CI Workflows & Action /.github/workflows/aspire-ci-cd.yml, /.github/workflows/ci-cd.yml, /.github/workflows/pr-validation.yml, /.github/actions/setup-postgres-connection/*	Add a composite action to build a Postgres connection-string, add a Setup PostgreSQL connection step, add PostGIS service to CI jobs, and map the action output into environment keys: ConnectionStrings__DefaultConnection, ConnectionStrings__Users, ConnectionStrings__Search, ConnectionStrings__meajudaai-db.
Docker Compose & Env files infrastructure/compose/base/postgres.yml, infrastructure/compose/environments/*	Switch base image to postgis/postgis:16-3.4, add healthcheck, volumes, restart policy, port mapping, and change default DB name to meajudaai.
DB init & validation scripts / infra docs infrastructure/test-database-init.ps1, infrastructure/test-database-init.sh, infrastructure/README.md, infrastructure/database/README.md	Add PowerShell/Bash DB validation scripts and documentation describing initialization checks, PostGIS, schemas, roles, and usage guidance.
DB Modules: search infrastructure/database/modules/search/00-roles.sql, .../01-permissions.sql	Add idempotent role creation (search_role, search_owner), grants to app roles, enable PostGIS, create search schema and set permissions, default privileges, and spatial grants.
DB Modules: location infrastructure/database/modules/location/00-roles.sql, .../01-permissions.sql	Add idempotent role creation (location_role, location_owner), grants, create location schema, set owner, permissions and default privileges.
App host / Postgres extensions src/Aspire/MeAjudaAi.AppHost/Extensions/PostgreSqlExtensions.cs	Switch local/test/development container image references to postgis/postgis:16-3.4 and update comments to reflect PostGIS usage.
Search module connection fallbacks src/Modules/Search/Infrastructure/Extensions.cs	Extend connection-string resolution to try DefaultConnection, then Search, then meajudaai-db before throwing; improved error message lists attempted keys.
Background jobs / Hangfire wiring src/Shared/Extensions/ServiceCollectionExtensions.cs, src/Shared/Jobs/HangfireExtensions.cs	Register NoOpBackgroundJobService as default; refactor dashboard setup to early-exit when disabled, perform runtime verification of Hangfire services with try/catch and logging, and guard dashboard setup.
E2E & Integration test helpers tests/MeAjudaAi.E2E.Tests/Base/TestTypes.cs, tests/MeAjudaAi.Integration.Tests/Base/ApiTestBase.cs, tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs	Add PaginatedResponse<T> and TokenResponse test records, add ReadJsonAsync<T> helper, and add authentication-focused integration tests.
Docs: Roadmap & TestContainers docs/roadmap.md, docs/testing/*	Expand Service Catalog 1.6 into a DDD+CQRS spec with new async API methods; add TestContainers E2E guidance and Portuguese docs for test infra.
SQL / misc infra changes infrastructure/database/modules/*, infrastructure/*	Add module docs, roles, permissions, and database usage notes across modules; add DB testing guidance and scripts.
Formatting-only / minor code edits multiple src/*, tests/* (see raw)	Numerous whitespace, using-order, small refactors and non-functional formatting changes across many files.

Sequence Diagram(s)

sequenceDiagram
    participant CI as CI Workflow
    participant Action as Setup Postgres Action
    participant Runner as Test Runner
    participant DB as Postgres+PostGIS

    CI->>DB: start PostGIS container (postgis/postgis:16-3.4)
    DB-->>CI: healthcheck ok (pg_isready)
    CI->>Action: invoke Setup PostgreSQL connection (inputs from secrets/fallbacks)
    Action-->>CI: output connection-string
    CI->>Runner: export ConnectionStrings__* = connection-string
    Runner->>DB: connect using ConnectionStrings__DefaultConnection (or Search / meajudaai-db)
    Runner->>DB: run migrations and tests
    DB-->>Runner: schemas, roles, extensions present

Loading

sequenceDiagram
    participant App as Application Startup
    participant DI as DI Container
    participant Hangfire as Hangfire Setup

    App->>DI: AddSharedServices()
    DI->>DI: register IBackgroundJobService = NoOpBackgroundJobService (default)

    App->>Hangfire: UseHangfireDashboardIfEnabled()
    alt dashboard disabled
        Hangfire->>App: log debug and return
    else dashboard enabled
        Hangfire->>DI: try resolve IBackgroundJobClient
        alt resolved
            Hangfire->>Hangfire: configure dashboard (auth, stats)
        else failed
            Hangfire->>App: log warning and skip dashboard
        end
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Areas to focus on:

• Verify CI action outputs and env var names match application configuration keys.
• Confirm SQL idempotence and that PostGIS enabling and grants are safe for existing environments.
• Check Hangfire runtime checks and default NoOp registration do not mask misconfiguration.
• Cross-check roadmap API method signatures against implemented interfaces/DTOs if applicable.

Possibly related PRs

• Users module implementation #1 — Similar CI workflow changes adding Postgres/PostGIS and mapping POSTGRES_CONNECTION into multiple ConnectionStrings__* env vars.
• Implementing documents module #9 — Overlapping changes to Postgres/PostGIS configuration and local image references in application startup/extensions.
• Implementing search module #10 — Related Search module work (migrations, PostGIS, permissions and search persistence wiring).

Poem

🐇
I hopped through YAML, scripts, and string,
Wove PostGIS ponds where databases sing,
Roles and schemas blink awake with cheer,
Tests connect, the dashboard listens near,
A happy rabbit whispers: infra's clear! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 48.84% 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 'refactor: code formatting and minor improvements across modules' accurately describes the primary focus of the changeset, which encompasses code formatting standardization and infrastructure/test improvements across multiple modules.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

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 (1)

infrastructure/compose/base/postgres.yml (1)

2-12: Standardize POSTGRES_DB default to lowercase for consistency with Aspire configuration

Verification confirms the inconsistency: PostgreSqlExtensions.cs (the Aspire configuration) defaults MainDatabase to "meajudaai" (lowercase), while the compose files default to MeAjudaAi (camelCase). This mismatch can cause connection issues when environment variables aren't explicitly set. The suggested change to use lowercase aligns the Docker Compose setup with the programmatic configuration.

Apply the change to infrastructure/compose/base/postgres.yml line 19:

-      POSTGRES_DB: ${POSTGRES_DB:-MeAjudaAi}
+      POSTGRES_DB: ${POSTGRES_DB:-meajudaai}

Also apply the same change to infrastructure/compose/environments/development.yml and infrastructure/compose/environments/production.yml to maintain consistency across all compose configurations.

🧹 Nitpick comments (15)

src/Modules/Search/Domain/Entities/SearchableProvider.cs (1)

235-252: Formatting changes align with PR objectives.

The blank lines added after guard clauses in Activate() and Deactivate() improve visual separation between precondition checks and business logic execution. This is consistent with the stated PR objective of applying dotnet format standardization.

Minor note: Other guard clauses in the file (e.g., UpdateBasicInfo, UpdateLocation, UpdateRating) do not follow the same blank-line-after-guard pattern. If this formatting rule is now part of your standardization, consider applying it uniformly across all guard clauses for consistency—though this can be deferred to a future formatting pass.

src/Modules/Users/Application/ModuleApi/UsersModuleApi.cs (1)

182-190: Suggest aligning with the Match pattern used in sibling methods.

The UsernameExistsAsync method uses IsSuccess check, while UserExistsAsync (lines 167–169) and EmailExistsAsync (lines 176–178) use the Match pattern. For consistency across the class, consider refactoring this method to use Match with named parameters:

  public async Task<Result<bool>> UsernameExistsAsync(string username, CancellationToken cancellationToken = default)
  {
      var query = new GetUserByUsernameQuery(username);
      var result = await getUserByUsernameHandler.HandleAsync(query, cancellationToken);

-     return result.IsSuccess
-         ? Result<bool>.Success(true)
-         : Result<bool>.Success(false);
+     return result.Match(
+         onSuccess: _ => Result<bool>.Success(true),
+         onFailure: _ => Result<bool>.Success(false)
+     );
  }

.github/workflows/aspire-ci-cd.yml (1)

104-108: Consider refactoring for readability.

The connection string declarations exceed YAML line length conventions (>120 characters), and the same connection string is duplicated across four environment variables.

Consider extracting the common connection string to a workflow-level environment variable:

+    env:
+      POSTGRES_CONNECTION: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB || 'meajudaai_test' }};Username=${{ secrets.POSTGRES_USER || 'postgres' }};Password=${{ secrets.POSTGRES_PASSWORD || 'test123' }}"
     steps:
       ...
       - name: Run tests
         env:
           ...
-          ConnectionStrings__DefaultConnection: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB || 'meajudaai_test' }};Username=${{ secrets.POSTGRES_USER || 'postgres' }};Password=${{ secrets.POSTGRES_PASSWORD || 'test123' }}"
-          ConnectionStrings__Users: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB || 'meajudaai_test' }};Username=${{ secrets.POSTGRES_USER || 'postgres' }};Password=${{ secrets.POSTGRES_PASSWORD || 'test123' }}"
-          ConnectionStrings__Search: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB || 'meajudaai_test' }};Username=${{ secrets.POSTGRES_USER || 'postgres' }};Password=${{ secrets.POSTGRES_PASSWORD || 'test123' }}"
-          ConnectionStrings__meajudaai-db: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB || 'meajudaai_test' }};Username=${{ secrets.POSTGRES_USER || 'postgres' }};Password=${{ secrets.POSTGRES_PASSWORD || 'test123' }}"
+          ConnectionStrings__DefaultConnection: ${{ env.POSTGRES_CONNECTION }}
+          ConnectionStrings__Users: ${{ env.POSTGRES_CONNECTION }}
+          ConnectionStrings__Search: ${{ env.POSTGRES_CONNECTION }}
+          ConnectionStrings__meajudaai-db: ${{ env.POSTGRES_CONNECTION }}

This reduces duplication and improves maintainability while keeping line lengths reasonable.

src/Modules/Search/Infrastructure/Extensions.cs (1)

23-32: Align connection string error message with new fallbacks

The new fallback chain (DefaultConnection → Search → meajudaai-db) is helpful and matches the broader infra changes, but the exception still says only 'DefaultConnection' not found, which is now misleading if all three are missing. Consider updating the message (and possibly referencing all supported keys) so config issues are easier to diagnose and stay in sync with Dapper/PostgresOptions usage.

tests/MeAjudaAi.Integration.Tests/Modules/Location/CepLookupIntegrationTests.cs (1)

171-199: Caching test currently doesn’t assert real cache behavior and may be timing‑fragile

The added await Task.Delay(100); helps avoid races with HybridCache, but it introduces time‑based flakiness on slower environments. Also, the test named WithCaching_ShouldCacheResults only checks that three calls return equivalent values, which would still be true even if responses weren’t cached and every call hit the HTTP mock.

If you want this to assert caching semantics more strongly, consider, for example:

• Instrumenting the mock handler to count HTTP calls and asserting that calls after the first stay below some small bound (while still allowing HybridCache’s initial extra calls), and/or
• Using a controllable time provider (if available via Shared.Time) instead of a fixed Task.Delay to make the test deterministic.

Otherwise, consider renaming the test to reflect that it’s validating consistent repeated results rather than actual cache hits.

tests/MeAjudaAi.Integration.Tests/Modules/Location/GeocodingIntegrationTests.cs (1)

131-159: Strengthen geocoding cache test to reduce timing flakiness and better assert caching

As in the CEP caching test, the Task.Delay(100) helps with HybridCache timing but can still be brittle on slower CI, and the test only verifies that three calls return consistent coordinates. That would also be true without caching as long as the mock always returns the same payload.

To better exercise cache behavior, you could:

• Track how many times the NominatimClient mock is invoked and assert that calls after the first stay within a small bound, and/or
• Replace the fixed delay with a deterministic mechanism (e.g., a test time provider, if the cache respects it) instead of sleeping.

If adding that complexity isn’t worth it right now, at least the current change doesn’t worsen behavior; it just doesn’t fully guarantee caching semantics.

.github/workflows/ci-cd.yml (1)

35-48: Consider aligning CI Postgres service with the PostGIS image/version used locally

The added Postgres service and connection string mappings are wired correctly for the tests. Given the rest of the stack now uses a PostGIS-enabled postgis/postgis:16-3.4, you may want CI to run against the same base to avoid subtle version/extension mismatches (especially once geospatial queries are exercised):

-      postgres:
-        image: postgres:15
+      postgres:
+        image: postgis/postgis:16-3.4

If yamllint’s line-length warnings become noisy, you can also shorten the ConnectionStrings__* entries by moving the connection string into a job-level env var and referencing it here instead of inlining the full value.

Also applies to: 69-72

.github/workflows/pr-validation.yml (1)

180-183: ConnectionStrings mapping is correct; consider reusing the robust builder for all

The new ConnectionStrings__* env vars correctly hook into .NET’s configuration. Note that only ConnectionStrings__DefaultConnection is rebuilt in the script with proper quoting/escaping; the Users, Search, and meajudaai-db strings embed secrets directly. If those ever contain characters like ;, they could be harder to parse than DefaultConnection.

Two possible cleanups:

• Reuse the same builder logic to construct ConnectionStrings__Users, __Search, and __meajudaai-db, or
• Prefer a single DefaultConnection and have modules bind from that instead of duplicating full connection strings.

This would also help shorten the long YAML lines yamllint warns about.

src/Aspire/MeAjudaAi.AppHost/Extensions/PostgreSqlExtensions.cs (2)

153-160: PostGIS image usage for test and dev is consistent; consider centralizing image/tag

Switching both local test and development paths to postgis/postgis:16-3.4 nicely aligns the Aspire host with the infra compose setup and the PostGIS-enabled SQL scripts. Since the same image/tag string now appears here and in compose, you might want to centralize it (e.g., config or constant) to avoid version drift across code and YAML when upgrading Postgres/PostGIS.

Also ensure your CI workflows’ Postgres service image is updated to a compatible PostGIS version so tests exercise the same capabilities as local runs.

Also applies to: 180-185

---

199-208: Schema layout comment is useful; keep it in sync with database docs

The inline list of schemas (users/providers/documents/search/location/catalogs/hangfire/identity/meajudaai_app/public) is a helpful summary of the single-DB multi-schema approach. Just make sure this stays aligned with infrastructure/database/README.md as new schemas like catalogs and identity are introduced or documented there to avoid divergence between code comments and infra docs.

infrastructure/database/modules/location/01-permissions.sql (1)

1-31: Location permissions script is consistent; optionally harden PUBLIC access

The schema ownership, role grants, default privileges, and search_path setup for location_role and meajudaai_app_role are all consistent with the modular RBAC approach used elsewhere.

If you’re aiming for stricter least-privilege by default, consider explicitly revoking PUBLIC privileges on the location schema and its objects here (unless you already do this globally), for example:

 CREATE SCHEMA IF NOT EXISTS location;

 -- Set explicit schema ownership
 ALTER SCHEMA location OWNER TO location_owner;
+
+-- Optional: lock down PUBLIC access on this schema
+REVOKE ALL ON SCHEMA location FROM PUBLIC;
+REVOKE ALL ON ALL TABLES IN SCHEMA location FROM PUBLIC;
+REVOKE ALL ON ALL SEQUENCES IN SCHEMA location FROM PUBLIC;

 GRANT USAGE ON SCHEMA location TO location_role;

That would ensure only the intended roles can use or create objects in the location schema.

infrastructure/database/modules/search/01-permissions.sql (1)

4-41: Permissions and defaults look consistent and idempotent; consider qualifying spatial_ref_sys

The PostGIS + schema/role grants and default privileges are set up cleanly and idempotently; this should behave well across repeated runs. One small robustness improvement is to fully qualify spatial_ref_sys with its schema to avoid search_path surprises:

-GRANT SELECT ON TABLE spatial_ref_sys TO search_role;
-GRANT SELECT ON TABLE spatial_ref_sys TO meajudaai_app_role;
+GRANT SELECT ON TABLE public.spatial_ref_sys TO search_role;
+GRANT SELECT ON TABLE public.spatial_ref_sys TO meajudaai_app_role;

infrastructure/test-database-init.sh (1)

73-86: Consider failing the script when a required schema/role/PostGIS is missing

Similar to the PowerShell variant, this script currently only logs missing schemas/roles/PostGIS in red but still exits 0, which limits its usefulness as a validation gate.

Introduce a has_errors flag that you set whenever a check fails and exit 1 at the end if any required artifact is missing, while keeping the human‑friendly output. For example:

has_errors=false

if [ "$RESULT" = "t" ]; then
  echo "   ✅ Schema '$schema' created successfully"
else
  echo "   ❌ Schema '$schema' NOT found"
  has_errors=true
fi

...

if [ "$has_errors" = true ]; then
  exit 1
fi

Also applies to: 91-110, 115-122, 124-131

tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs (1)

52-67: RateLimiting_ShouldBeConfiguredCorrectly doesn’t actually assert rate‑limit behavior

Right now a single request that accepts either OK or TooManyRequests will pass whether rate limiting is enabled, disabled, or misconfigured, so the test name oversells what it guarantees. Consider either (a) renaming it to reflect that it only documents endpoint reachability under a rate-limited pipeline, or (b) extending it to issue multiple requests and assert a concrete behavior (e.g., 429 after N calls or presence of specific rate-limit headers), while keeping it deterministic enough for CI.

docs/testing/test_infrastructure.md (1)

137-152: Optional PT‑BR wording tweak in the “Performance” section

Static analysis flagged “Performance” as an anglicism here; if you want to keep terminology strictly in PT‑BR, you could rename the heading to “Desempenho” (and adjust any references). This is purely stylistic—the current wording is understandable and common in tech docs.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6de3853 and c98b757.

📒 Files selected for processing (50)

• .github/workflows/aspire-ci-cd.yml (1 hunks)
• .github/workflows/ci-cd.yml (2 hunks)
• .github/workflows/pr-validation.yml (1 hunks)
• docs/roadmap.md (1 hunks)
• docs/testing/integration_tests.md (1 hunks)
• docs/testing/test_infrastructure.md (1 hunks)
• infrastructure/README.md (1 hunks)
• infrastructure/compose/base/postgres.yml (2 hunks)
• infrastructure/database/README.md (2 hunks)
• infrastructure/database/modules/location/00-roles.sql (1 hunks)
• infrastructure/database/modules/location/01-permissions.sql (1 hunks)
• infrastructure/database/modules/search/00-roles.sql (1 hunks)
• infrastructure/database/modules/search/01-permissions.sql (1 hunks)
• infrastructure/test-database-init.ps1 (1 hunks)
• infrastructure/test-database-init.sh (1 hunks)
• src/Aspire/MeAjudaAi.AppHost/Extensions/PostgreSqlExtensions.cs (3 hunks)
• src/Bootstrapper/MeAjudaAi.ApiService/Program.cs (1 hunks)
• src/Modules/Documents/Application/ModuleApi/DocumentsModuleApi.cs (7 hunks)
• src/Modules/Documents/Tests/Unit/Application/ModuleApi/DocumentsModuleApiTests.cs (2 hunks)
• src/Modules/Location/Domain/ValueObjects/Address.cs (2 hunks)
• src/Modules/Location/Domain/ValueObjects/Cep.cs (1 hunks)
• src/Modules/Location/Infrastructure/Extensions.cs (1 hunks)
• src/Modules/Location/Infrastructure/ExternalApis/Clients/BrasilApiCepClient.cs (1 hunks)
• src/Modules/Location/Infrastructure/ExternalApis/Clients/NominatimClient.cs (4 hunks)
• src/Modules/Location/Infrastructure/ExternalApis/Clients/OpenCepClient.cs (1 hunks)
• src/Modules/Location/Infrastructure/ExternalApis/Clients/ViaCepClient.cs (1 hunks)
• src/Modules/Location/Infrastructure/ExternalApis/Responses/ViaCepResponse.cs (1 hunks)
• src/Modules/Providers/Tests/Unit/Domain/Entities/ProviderTests.cs (1 hunks)
• src/Modules/Search/API/Endpoints/SearchProvidersEndpoint.cs (1 hunks)
• src/Modules/Search/Application/DTOs/LocationDto.cs (1 hunks)
• src/Modules/Search/Application/Queries/SearchProvidersQuery.cs (1 hunks)
• src/Modules/Search/Domain/Entities/SearchableProvider.cs (2 hunks)
• src/Modules/Search/Infrastructure/Extensions.cs (1 hunks)
• src/Modules/Search/Infrastructure/Persistence/Migrations/20251114205434_InitialCreate.cs (1 hunks)
• src/Modules/Search/Infrastructure/Persistence/SearchDbContext.cs (1 hunks)
• src/Modules/Search/Tests/Integration/SearchIntegrationTestBase.cs (3 hunks)
• src/Modules/Search/Tests/Integration/SearchableProviderRepositoryIntegrationTests.cs (2 hunks)
• src/Modules/Search/Tests/Unit/Application/Queries/SearchProvidersQueryTests.cs (1 hunks)
• src/Modules/Users/Application/ModuleApi/UsersModuleApi.cs (1 hunks)
• src/Modules/Users/Tests/Unit/Domain/Entities/UserTests.cs (1 hunks)
• src/Shared/Contracts/Modules/Documents/IDocumentsModuleApi.cs (8 hunks)
• src/Shared/Contracts/Modules/Search/DTOs/ModuleLocationDto.cs (1 hunks)
• src/Shared/Extensions/ServiceCollectionExtensions.cs (1 hunks)
• src/Shared/Jobs/HangfireExtensions.cs (2 hunks)
• tests/MeAjudaAi.E2E.Tests/Base/TestTypes.cs (1 hunks)
• tests/MeAjudaAi.E2E.Tests/Integration/SearchProvidersEndpointTests.cs (1 hunks)
• tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs (1 hunks)
• tests/MeAjudaAi.Integration.Tests/Authorization/PermissionAuthorizationIntegrationTests.cs (3 hunks)
• tests/MeAjudaAi.Integration.Tests/Modules/Location/CepLookupIntegrationTests.cs (2 hunks)
• tests/MeAjudaAi.Integration.Tests/Modules/Location/GeocodingIntegrationTests.cs (3 hunks)

🧰 Additional context used

🧬 Code graph analysis (11)

src/Modules/Providers/Tests/Unit/Domain/Entities/ProviderTests.cs (1)

tests/MeAjudaAi.Shared.Tests/Mocks/MockDateTimeProvider.cs (3)

• MockDateTimeProvider (9-64)
• MockDateTimeProvider (16-19)
• MockDateTimeProvider (25-28)

src/Shared/Jobs/HangfireExtensions.cs (2)

src/Shared/Extensions/ServiceCollectionExtensions.cs (1)

• IApplicationBuilder (77-85)

src/Shared/Jobs/HangfireAuthorizationFilter.cs (1)

• HangfireAuthorizationFilter (10-37)

src/Modules/Search/Infrastructure/Extensions.cs (1)

src/Shared/Database/DapperConnection.cs (1)

• GetConnectionString (11-22)

tests/MeAjudaAi.Integration.Tests/Authorization/PermissionAuthorizationIntegrationTests.cs (1)

tests/MeAjudaAi.Shared.Tests/Auth/ConfigurableTestAuthenticationHandler.cs (3)

• ConfigureAdmin (66-69)
• ConfigureRegularUser (71-74)
• ClearConfiguration (76-81)

tests/MeAjudaAi.E2E.Tests/Base/TestTypes.cs (1)

src/Shared/Authorization/Keycloak/KeycloakPermissionResolver.cs (1)

• TokenResponse (408-418)

tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs (2)

tests/MeAjudaAi.Integration.Tests/Base/ApiTestBase.cs (1)

• ApiTestBase (22-229)

tests/MeAjudaAi.Shared.Tests/Extensions/TestCancellationExtensions.cs (1)

• CancellationToken (13-13)

src/Modules/Search/Tests/Integration/SearchableProviderRepositoryIntegrationTests.cs (1)

src/Modules/Search/Domain/Entities/SearchableProvider.cs (1)

• UpdateRating (197-212)

src/Modules/Users/Tests/Unit/Domain/Entities/UserTests.cs (1)

tests/MeAjudaAi.Shared.Tests/Mocks/MockDateTimeProvider.cs (3)

• MockDateTimeProvider (9-64)
• MockDateTimeProvider (16-19)
• MockDateTimeProvider (25-28)

src/Shared/Extensions/ServiceCollectionExtensions.cs (1)

src/Shared/Jobs/NoOpBackgroundJobService.cs (1)

• NoOpBackgroundJobService (9-25)

src/Modules/Search/Infrastructure/Persistence/SearchDbContext.cs (1)

src/Modules/Search/Infrastructure/Persistence/SearchDbContextFactory.cs (1)

• SearchDbContext (12-32)

src/Modules/Location/Infrastructure/Extensions.cs (1)

src/Modules/Location/Infrastructure/ExternalApis/Clients/NominatimClient.cs (1)

• NominatimClient (19-122)

🪛 GitHub Check: YAML Syntax Check

.github/workflows/pr-validation.yml

[warning] 183-183:
183:121 [line-length] line too long (185 > 120 characters)

---

[warning] 182-182:
182:121 [line-length] line too long (179 > 120 characters)

---

[warning] 181-181:
181:121 [line-length] line too long (178 > 120 characters)

---

[warning] 180-180:
180:121 [line-length] line too long (190 > 120 characters)

.github/workflows/aspire-ci-cd.yml

[warning] 106-106:
106:121 [line-length] line too long (225 > 120 characters)

---

[warning] 105-105:
105:121 [line-length] line too long (237 > 120 characters)

.github/workflows/ci-cd.yml

[warning] 72-72:
72:121 [line-length] line too long (232 > 120 characters)

---

[warning] 71-71:
71:121 [line-length] line too long (226 > 120 characters)

---

[warning] 70-70:
70:121 [line-length] line too long (225 > 120 characters)

---

[warning] 69-69:
69:121 [line-length] line too long (237 > 120 characters)

🪛 LanguageTool

docs/testing/test_infrastructure.md

[locale-violation] ~137-~137: “Performance” é um estrangeirismo. É preferível dizer “desempenho”, “atuação”, “apresentação”, “espetáculo” ou “interpretação”.
Context: ...vice, MockKeycloakService>(); } ``` ## Performance ### Tempos Típicos - **Inicialização ...

(PT_BARBARISMS_REPLACE_PERFORMANCE)

docs/roadmap.md

[style] ~225-~225: Para conferir mais clareza ao seu texto, busque usar uma linguagem mais concisa.
Context: ...serviços que prestadores podem oferecer através de um catálogo admin-managed. #### **Arqu...

(ATRAVES_DE_POR_VIA)

---

[misspelling] ~284-~284: Esta é uma palavra só.
Context: ...esAsync integrado - DI registration com auto-migration support 4. API Layer ✅ - **Endpoin...

(AUTO)

---

[grammar] ~304-~304: Se ‘endpoints’ é um substantivo, ‘Todos’ no plural exige um segundo artigo.
Context: ...ices/{id}` - Deletar - Autorização: Todos endpoints requerem role Admin - Versionamento...

(TODOS_FOLLOWED_BY_NOUN_PLURAL)

⏰ 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). (4)

• GitHub Check: Code Quality Checks
• GitHub Check: Security Scan
• GitHub Check: code-analysis
• GitHub Check: build-and-test

🔇 Additional comments (44)

src/Modules/Search/Application/DTOs/LocationDto.cs (1)

1-22: Well-structured DTO with proper validation.

The LocationDto is well-designed: sealed record ensures immutability, Range attributes enforce valid geographic coordinate boundaries, and XML documentation is clear and helpful. The whitespace adjustment aligns with your dotnet format standardization goals.

src/Shared/Contracts/Modules/Search/DTOs/ModuleLocationDto.cs (1)

1-17: LGTM!

The DTO is well-structured with proper immutability semantics (sealed record, required properties with init accessors), clear XML documentation, and appropriate coordinate ranges in doc comments. The formatting change (blank line removal) aligns with dotnet format standardization.

src/Modules/Location/Infrastructure/Extensions.cs (1)

41-52: Formatting improvements enhance readability and consistency. ✓

The blank lines added after the OpenCep registration (line 41) and before the UserAgent configuration (line 47) create consistent visual separation between logical configuration blocks. The restructuring of the UserAgent assignment (lines 48–51) also improves clarity by positioning the comment directly above the configuration key it describes.

These formatting-only adjustments align well with the PR's dotnet format standardization objective and do not alter any functional behavior.

src/Modules/Search/Domain/Entities/SearchableProvider.cs (1)

1-263: Domain entity structure and logic are sound.

The SearchableProvider aggregate root is well-structured with proper encapsulation, comprehensive validation, and clear state management. Guard clauses prevent invalid transitions, and all mutations properly update the aggregate state via MarkAsUpdated(). The separation of factory methods (Create vs. Reconstitute) appropriately restricts object construction patterns for an internal-facing read model.

src/Modules/Location/Infrastructure/ExternalApis/Responses/ViaCepResponse.cs (1)

15-15: LGTM! Formatting change aligns with code standardization.

This whitespace adjustment is part of the broader dotnet format standardization effort mentioned in the PR description. The DTO structure and documentation remain clear and appropriate for the ViaCEP API response model.

src/Modules/Users/Application/ModuleApi/UsersModuleApi.cs (6)

126-133: Formatting standardization looks good.

The indentation adjustment on line 127 aligns with dotnet format conventions. The Match pattern and null-coalescing logic are correct—returns Success(null) when user is null or 404 error, otherwise returns the mapped DTO or failure result.

---

135-147: Pattern is consistent and correct.

The Match pattern here is identical to GetUserByIdAsync and properly handles the success, null, and error cases as expected.

---

149-162: Good use of batch queries to avoid N+1 problem.

The implementation correctly uses GetUsersByIdsQuery to fetch multiple users efficiently and properly maps the results to ModuleUserBasicDto.

---

164-171: Graceful degradation pattern is appropriate.

The method correctly returns Success(false) on error, which is a reasonable design choice for an existence check—errors are treated as "not found" rather than failure propagation.

---

173-180: Consistent with UserExistsAsync pattern.

Same graceful degradation approach—returns Success(false) on error or when user is null.

---

34-78: Health check and availability logic is well-designed.

The IsAvailableAsync method properly validates both infrastructure health and basic operations functionality. Logging at appropriate levels (Debug, Warning, Error) and handling OperationCanceledException appropriately shows good defensive programming.

src/Modules/Users/Tests/Unit/Domain/Entities/UserTests.cs (1)

15-17: LGTM! Formatting standardization applied.

The ternary operator has been reformatted to a more compact, single-line style. This aligns with standard C# formatting conventions and is consistent with the PR's objective to standardize code style using dotnet format. The logic and behavior remain unchanged.

src/Modules/Documents/Tests/Unit/Application/ModuleApi/DocumentsModuleApiTests.cs (1)

62-81: Formatting changes look good; test logic remains solid.

The blank line additions improve readability by separating the test data setup from mock configuration. The test maintains proper AAA pattern and comprehensive coverage across happy/unhappy paths.

src/Shared/Contracts/Modules/Documents/IDocumentsModuleApi.cs (1)

17-90: Consistent parameter formatting across interface methods.

Parameter layout change improves signature readability and aligns with C# conventions. All method contracts remain stable with comprehensive XML documentation intact.

src/Modules/Documents/Application/ModuleApi/DocumentsModuleApi.cs (1)

254-427: Formatting changes consistently improve logical section separation.

Blank lines appropriately delineate fetch → validate → process → return flow across all methods. Implementation quality is strong: comprehensive error handling, clear documentation of design decisions (e.g., performance reasoning for deferring specialized queries), and proper cancellation token propagation throughout.

src/Bootstrapper/MeAjudaAi.ApiService/Program.cs (1)

24-35: DI registration formatting change is a no-op

The AddApiServices call formatting looks consistent with the surrounding DI registrations, and there’s no behavioral impact from this change.

src/Modules/Location/Domain/ValueObjects/Address.cs (1)

95-105: Address value object formatting tightened without changing behavior

The spacing tweaks inside ToString and GetEqualityComponents are purely cosmetic; the address string representation and equality semantics stay the same.

Also applies to: 107-124

src/Modules/Location/Domain/ValueObjects/Cep.cs (1)

41-47: Formatted CEP property reflow is cosmetic only

The rewrapped expression-bodied Formatted property keeps the same condition and result; CEP creation/validation and formatting behavior are unchanged.

src/Modules/Location/Infrastructure/ExternalApis/Clients/ViaCepClient.cs (1)

1-1: LGTM! Duplicate using statement removed.

Consolidating the using System.Text.Json directive at the top and removing the duplicate improves code organization and follows standard C# conventions.

src/Modules/Providers/Tests/Unit/Domain/Entities/ProviderTests.cs (1)

14-19: LGTM! Formatting applied consistently.

The ternary operator has been reformatted for clarity, making each branch more visible. This aligns with the project's code formatting standards.

src/Modules/Search/Infrastructure/Persistence/Migrations/20251114205434_InitialCreate.cs (1)

1-1: LGTM! BOM character removed for encoding consistency.

Removing the Byte Order Mark ensures the migration file is correctly parsed across all environments, which is particularly important for the PostGIS-enabled database initialization workflows.

docs/testing/integration_tests.md (1)

6-10: LGTM! Helpful documentation cross-references added.

Adding links to related documentation improves discoverability and helps developers navigate the test infrastructure documentation more effectively.

src/Modules/Location/Infrastructure/ExternalApis/Clients/BrasilApiCepClient.cs (1)

1-1: LGTM! Consistent formatting across Location API clients.

Consolidating the using directive and removing duplicates maintains consistency with the other API clients in the Location module (e.g., ViaCepClient).

src/Modules/Search/Tests/Unit/Application/Queries/SearchProvidersQueryTests.cs (1)

39-42: LGTM! Unnecessary blank line removed.

The whitespace cleanup improves code density while maintaining readability.

src/Modules/Search/Application/Queries/SearchProvidersQuery.cs (1)

24-43: LGTM! Improved readability in cache key construction.

The added blank lines help visually separate the logical groups (rating, services, tiers) in the cache key generation, making the method easier to scan.

src/Modules/Search/API/Endpoints/SearchProvidersEndpoint.cs (1)

148-150: LGTM! Line wrapping adjusted for readability.

The reformatted method call makes the generic type parameters more visible and likely addresses line length constraints.

src/Shared/Extensions/ServiceCollectionExtensions.cs (1)

70-72: LGTM! Good default implementation for testing scenarios.

The no-op default for IBackgroundJobService is a solid design choice that prevents background job execution in test environments while allowing modules to explicitly register HangfireBackgroundJobService when needed.

src/Modules/Location/Infrastructure/ExternalApis/Clients/NominatimClient.cs (1)

1-2: Code formatting improvements applied.

The using directive reordering and line wrapping changes throughout this file are formatting-only improvements with no functional impact.

tests/MeAjudaAi.E2E.Tests/Integration/SearchProvidersEndpointTests.cs (1)

126-131: Formatting improvements applied.

The blank line adjustment and lambda reformatting are formatting-only changes with no functional impact.

docs/roadmap.md (1)

221-378: Excellent documentation of the Service Catalog implementation.

The expanded documentation thoroughly captures the completed Service Catalog module with clear architecture details, API specifications, database schema, and integration points. This provides valuable context for developers working with this module.

src/Modules/Location/Infrastructure/ExternalApis/Clients/OpenCepClient.cs (1)

1-1: Code formatting applied.

Using directive reordering is a formatting-only change with no functional impact.

src/Modules/Search/Tests/Integration/SearchableProviderRepositoryIntegrationTests.cs (1)

76-76: Formatting improvements applied.

The blank line additions improve test readability with no functional impact.

Also applies to: 142-142, 145-145

tests/MeAjudaAi.E2E.Tests/Base/TestTypes.cs (1)

28-33: Review comment is incorrect—it identifies the wrong type as the duplicate.

The original comment claims that TokenResponse at KeycloakPermissionResolver.cs lines 407-417 duplicates the test version. However, the TokenResponse in KeycloakPermissionResolver lacks a RefreshToken property, making it structurally different from the test version.

The actual structural duplicate is KeycloakTokenResponse (src/Modules/Users/Infrastructure/Identity/Keycloak/Models/KeycloakTokenResponse.cs), which contains all four properties including RefreshToken. The test could reuse this existing public type instead of declaring its own, but the review's cited location and analysis are misaligned with the actual codebase structure.

Likely an incorrect or invalid review comment.

src/Modules/Search/Infrastructure/Persistence/SearchDbContext.cs (1)

24-28: DI constructor formatting-only change looks good

The runtime DI constructor remains unchanged in signature and behavior; this is a pure formatting cleanup.

tests/MeAjudaAi.Integration.Tests/Modules/Location/CepLookupIntegrationTests.cs (1)

1-13: Using cleanup is fine

Consolidating System.Net into a single using at the top keeps imports tidy and avoids duplicates.

tests/MeAjudaAi.Integration.Tests/Modules/Location/GeocodingIntegrationTests.cs (1)

1-13: Using directive change is straightforward

Adding System.Net once at the top to support HttpStatusCode usages is clean and consistent.

src/Modules/Search/Tests/Integration/SearchIntegrationTestBase.cs (1)

58-88: Search integration test base formatting changes preserve behavior

The DbContext setup (including PostGIS and snake_case conventions), repository registration, and PostGIS availability check remain semantically identical; changes are purely formatting/clarity improvements.

Also applies to: 100-137

tests/MeAjudaAi.Integration.Tests/Authorization/PermissionAuthorizationIntegrationTests.cs (2)

7-10: Class XML doc improvement is clear and helpful

The extended summary nicely documents the authorization scenarios covered by these integration tests; no changes needed.

---

23-44: Consistent Arrange/Act/Assert comments improve test readability

The added Arrange/Act/Assert markers are consistent across tests and make the flow explicit without altering behavior. Looks good as-is.

Also applies to: 49-57, 62-73

infrastructure/README.md (1)

230-294: Database initialization testing docs are thorough and aligned

The new section clearly explains how to run the init test scripts, what they validate (schemas, roles, PostGIS, sequence), and how to connect afterward. The added note about monitoring security advisories rounds out the infra story well.

infrastructure/database/README.md (1)

17-28: Module and PostGIS documentation is consistent and helpful

The expanded module tree (including documents/search/location), the Hangfire access clarification, the schema table, and the PostGIS section give a clear picture of how schemas and roles are organized. This aligns well with the new SQL scripts and infra changes.

Also applies to: 57-75, 76-84

infrastructure/database/modules/location/00-roles.sql (1)

4-55: Role creation and grants are safely idempotent

The DO blocks for creating location_role/location_owner and the membership checks before GRANT make this script safely rerunnable, and the NOLOGIN pattern plus comments keep credentials out of versioned DDL. This structure looks solid.

infrastructure/database/modules/search/00-roles.sql (1)

1-55: Role/permission setup for search module is clear and idempotent

The DO blocks correctly guard role creation and membership GRANTs, and the separation between NOLOGIN grouping roles and environment-specific LOGIN users is a solid security practice. Just double-check that this script runs after the cluster-wide creation of meajudaai_app_role/meajudaai_app_owner and before 01-permissions.sql, so all GRANTs and default privileges are wired up in the expected order.

tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs (1)

13-50: Authentication integration tests cover the key authorization paths

The three tests around unauthenticated, regular user, and admin access clearly exercise the expected authorization behavior on /api/v1/users, and the use of AuthConfig plus the shared Client/cancellation token keeps the setup consistent with the rest of the integration suite. Just ensure the project has the appropriate xUnit usings (global or local) so [Fact] and TestContext resolve as intended.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

tests/MeAjudaAi.Integration.Tests/Modules/Documents/DocumentsApiTests.cs (1)

58-58: Apply the same refactoring for consistency.

Lines 58 and 121 still use response.Content.ReadFromJsonAsync<T>() directly instead of the new ReadJsonAsync<T> helper. While these tests are currently skipped or conditional, updating them maintains consistency and prevents future issues if they're re-enabled.

Apply this diff to update line 58:

-        var result = await response.Content.ReadFromJsonAsync<UploadDocumentResponse>();
+        var result = await ReadJsonAsync<UploadDocumentResponse>(response.Content);

Apply this diff to update line 121:

-        var uploadResult = await uploadResponse.Content.ReadFromJsonAsync<UploadDocumentResponse>();
+        var uploadResult = await ReadJsonAsync<UploadDocumentResponse>(uploadResponse.Content);

Also applies to: 121-121

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c98b757 and 8f00f57.

📒 Files selected for processing (2)

• tests/MeAjudaAi.Integration.Tests/Base/ApiTestBase.cs (2 hunks)
• tests/MeAjudaAi.Integration.Tests/Modules/Documents/DocumentsApiTests.cs (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/MeAjudaAi.Integration.Tests/Base/ApiTestBase.cs (1)

src/Shared/Serialization/SerializationDefaults.cs (1)

• SerializationDefaults (7-37)

⏰ 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). (4)

• GitHub Check: Code Quality Checks
• GitHub Check: Security Scan
• GitHub Check: build-and-test
• GitHub Check: code-analysis

🔇 Additional comments (2)

tests/MeAjudaAi.Integration.Tests/Modules/Documents/DocumentsApiTests.cs (1)

128-128: LGTM! Using shared serialization options improves test consistency.

The refactoring to use ReadJsonAsync<T> ensures that test deserialization uses the same SerializationDefaults.Api options as the production API, including enum converters and custom converters like GeoPointConverter.

Also applies to: 179-179

tests/MeAjudaAi.Integration.Tests/Base/ApiTestBase.cs (1)

1-1: LGTM! Well-implemented helper method.

The new ReadJsonAsync<T> helper centralizes JSON deserialization for integration tests using SerializationDefaults.Api, which ensures consistency with the production API's serialization behavior, including enum and custom type converters.

Also applies to: 7-7, 232-239

[coderabbitai]

Actionable comments posted: 4

Caution

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

⚠️ Outside diff range comments (1)

.github/workflows/pr-validation.yml (1)

161-184: Address YAML line length; extract duplicated connection string logic (cross-workflow concern).

Line 161 exceeds the 120-character limit (currently 173 characters). This connection string pattern and .NET mapping is duplicated identically across aspire-ci-cd.yml, ci-cd.yml, and pr-validation.yml.

-          POSTGRES_CONNECTION: "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB }};Username=${{ secrets.POSTGRES_USER }};Password=${{ secrets.POSTGRES_PASSWORD }}"
+          POSTGRES_CONNECTION: >-
+            "Host=localhost;Port=5432;Database=${{ secrets.POSTGRES_DB }};Username=${{ secrets.POSTGRES_USER }};Password=${{ secrets.POSTGRES_PASSWORD }}"

However, the broader issue is that all three workflows now define this identically. Recommend refactoring into a reusable composite action or extracting into a shared workflow to reduce duplication and maintenance burden.

🧹 Nitpick comments (2)

infrastructure/test-database-init.sh (1)

80-81: Mitigate SQL injection risk by quoting schema and role identifiers.

While the script uses hardcoded schema and role names (low immediate risk), best practice is to quote identifiers in SQL queries to prevent issues if this script is later modified to accept external input.

Quote identifiers using PostgreSQL's double-quote syntax or use $$...$$ quoting for safety:

-    QUERY="SELECT EXISTS(SELECT 1 FROM information_schema.schemata WHERE schema_name = '$schema');"
+    QUERY="SELECT EXISTS(SELECT 1 FROM information_schema.schemata WHERE schema_name = '\"$schema\"');"

Alternatively, parameterize queries if the PostgreSQL client supports it, or use a safer approach:

# Option 1: Quote identifiers explicitly
QUERY="SELECT EXISTS(SELECT 1 FROM information_schema.schemata WHERE schema_name = '$schema');"

# Option 2: Use array of pre-validated values (current approach - already safe here)
# Your current approach is actually safe since SCHEMAS is hardcoded

Since your SCHEMAS and ROLES arrays are hardcoded, the risk is currently low. However, if you plan to make the script configurable in the future, apply this pattern preemptively.

Also applies to: 106-107, 120-121

src/Shared/Jobs/HangfireExtensions.cs (1)

21-26: Doc comment overstates the hard requirement on AddHangfire

The method now gracefully handles the case where AddHangfire wasn’t called (it logs a warning and returns), so the summary line “Requer que AddHangfire tenha sido chamado anteriormente.” is no longer strictly accurate. Consider rephrasing to indicate that the dashboard is only configured if Hangfire has been registered, instead of stating it as a hard requirement.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8f00f57 and def9151.

📒 Files selected for processing (15)

• .github/workflows/aspire-ci-cd.yml (1 hunks)
• .github/workflows/ci-cd.yml (2 hunks)
• .github/workflows/pr-validation.yml (3 hunks)
• docs/testing/test_infrastructure.md (1 hunks)
• infrastructure/compose/base/postgres.yml (2 hunks)
• infrastructure/compose/environments/development.yml (1 hunks)
• infrastructure/compose/environments/production.yml (1 hunks)
• infrastructure/database/modules/location/01-permissions.sql (1 hunks)
• infrastructure/database/modules/search/01-permissions.sql (1 hunks)
• infrastructure/test-database-init.ps1 (1 hunks)
• infrastructure/test-database-init.sh (1 hunks)
• src/Modules/Search/Infrastructure/Extensions.cs (1 hunks)
• src/Modules/Users/Application/ModuleApi/UsersModuleApi.cs (2 hunks)
• src/Shared/Jobs/HangfireExtensions.cs (2 hunks)
• tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• infrastructure/compose/environments/development.yml

🚧 Files skipped from review as they are similar to previous changes (5)

• tests/MeAjudaAi.Integration.Tests/Authentication/AuthenticationTests.cs
• infrastructure/test-database-init.ps1
• src/Modules/Users/Application/ModuleApi/UsersModuleApi.cs
• src/Modules/Search/Infrastructure/Extensions.cs
• infrastructure/database/modules/location/01-permissions.sql

🧰 Additional context used

🧬 Code graph analysis (1)

src/Shared/Jobs/HangfireExtensions.cs (2)

src/Shared/Extensions/ServiceCollectionExtensions.cs (1)

• IApplicationBuilder (77-85)

src/Shared/Jobs/HangfireAuthorizationFilter.cs (1)

• HangfireAuthorizationFilter (10-37)

🪛 GitHub Check: build-and-test

src/Shared/Jobs/HangfireExtensions.cs

[failure] 56-56:
'HangfireExtensions': static types cannot be used as type arguments

---

[failure] 56-56:
'HangfireExtensions': static types cannot be used as type arguments

🪛 GitHub Check: YAML Syntax Check

.github/workflows/aspire-ci-cd.yml

[warning] 98-98:
98:121 [line-length] line too long (220 > 120 characters)

.github/workflows/ci-cd.yml

[warning] 68-68:
68:121 [line-length] line too long (220 > 120 characters)

.github/workflows/pr-validation.yml

[warning] 161-161:
161:121 [line-length] line too long (173 > 120 characters)

🪛 markdownlint-cli2 (0.18.1)

docs/testing/test_infrastructure.md

11-11: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

175-175: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

183-183: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

191-191: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

208-208: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ 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). (3)

• GitHub Check: Code Quality Checks
• GitHub Check: Security Scan
• GitHub Check: code-analysis

🔇 Additional comments (12)

docs/testing/test_infrastructure.md (1)

1-278: Documentation structure, content quality, and technical accuracy are solid.

The documentation comprehensively covers the TestContainers-based E2E testing infrastructure with clear architecture explanations, practical usage examples, best practices, troubleshooting guidance, and a migration path. Code examples are idiomatic and well-aligned with the infrastructure described in the PR objectives.

infrastructure/database/modules/search/01-permissions.sql (2)

38-40: Verify providers schema exists before running this script.

The script grants read-only access to the providers schema (lines 38-40), but does not check if the schema exists. If this permissions script is executed before the providers schema is created, these GRANT statements will fail and block the entire script.

Consider either:

1. Adding a conditional check or documenting the hard dependency on providers schema creation order
2. Wrapping in error handling (e.g., DO block with exception handling)

---

1-47: SQL permissions structure looks sound overall.

The file follows PostgreSQL best practices:

• Logical progression from extension setup through ownership to privilege delegation
• Appropriate use of IF NOT EXISTS for idempotent operations
• Well-documented role hierarchy (search_role for direct access, meajudaai_app_role for application layer)
• Good separation of concerns with read-only cross-schema access for providers
• Default privileges correctly configured for future objects

Ensure that 00-roles.sql is guaranteed to execute before this script (the naming convention suggests this, but verify it's enforced by your tooling/migration runner).

.github/workflows/aspire-ci-cd.yml (1)

29-30: Note: Image version inconsistency.

This workflow uses postgres:15 while other CI workflows (ci-cd.yml, pr-validation.yml) use postgis/postgis:16-3.4. Verify whether this is intentional for Aspire-specific validation or if it should be aligned with the PostGIS-enabled setup in the rest of the PR.

infrastructure/compose/environments/production.yml (1)

35-35: LGTM. Database name normalization is consistent across environments.

The change aligns with development.yml and the base postgres.yml configuration, ensuring consistent database naming across all deployment environments.

.github/workflows/ci-cd.yml (1)

35-48: LGTM. Postgres service configuration is sound with PostGIS support.

The service definition includes proper health checks, port mappings, and a PostGIS-enabled image. This enables geospatial query support for the search module.

.github/workflows/pr-validation.yml (1)

72-86: LGTM. Postgres service with PostGIS support is properly configured.

The health check and environment setup are appropriate for test validation.

infrastructure/compose/base/postgres.yml (1)

2-2: LGTM. Infrastructure upgrades are well-structured with operational best practices.

The shift to postgis/postgis:16-3.4 with consistent naming, health checks, proper restart policies, and volume mounts for initialization scripts is solid. The configuration enables automatic schema initialization and health monitoring.

Also applies to: 15-15, 18-18, 21-33

infrastructure/test-database-init.sh (1)

1-149: LGTM. Database initialization validation script is comprehensive and well-structured.

The script properly validates schemas, roles, and PostGIS extension with clear error reporting. The health check loop is robust, and the output provides helpful debugging information. Docker Compose integration is correct.

src/Shared/Jobs/HangfireExtensions.cs (3)

4-4: DI extensions import is correct and required

Adding using Microsoft.Extensions.DependencyInjection; here is appropriate so GetService<T>() resolves without fully qualifying the extension method.

---

30-53: Service-availability guard around dashboard setup looks solid

The early return when the dashboard is disabled, plus the runtime check for IBackgroundJobClient (with warning logs and a try/catch fallback) gives you a safe, self-diagnosing path when Hangfire isn’t configured. This is a good improvement over blindly configuring the dashboard.

---

60-86: Great! Found the Hangfire version. Let me verify the API for version 1.8.21:

Code changes are correct for Hangfire 1.8.21 API; no action needed

The StatsPollingInterval property is an int type representing milliseconds (default 2000), and your code correctly defaults to 5000ms (5 seconds). The DisplayStorageConnectionString is a bool property (default true), and your choice to default to false is a reasonable security consideration. Both the StatsPollingInterval validation (rejecting values ≤ 0) and DisplayStorageConnectionString configuration align perfectly with Hangfire 1.8.21's DashboardOptions API. The dashboard path normalization is also standard practice. No changes required.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

infrastructure/test-database-init.sh (1)

136-136: Log filtering may mask initialization issues if patterns don't match.

Line 136 filters container logs for "Initializing|Setting up|completed" but doesn't verify if initialization logs actually exist. If the PostgreSQL image outputs different log markers, legitimate initialization may go unreported.

Consider logging the full container initialization output as a fallback:

docker logs meajudaai-postgres 2>&1 | grep -E "Initializing|Setting up|completed" || \
  (echo "⚠️  No matching initialization logs found. Full output:" && docker logs meajudaai-postgres)

.github/actions/setup-postgres-connection/README.md (1)

49-51: Add language identifier to fenced code block.

Line 49–51 has a fenced code block without a language specifier, triggering a linter warning. While this won't break functionality, it reduces IDE syntax highlighting and linting compatibility.

-\`\`\`
+\`\`\`text
 Host={host};Port={port};Database={database};Username={username};Password={password}
-\`\`\`
+\`\`\`

src/Shared/Jobs/HangfireExtensions.cs (1)

55-57: Consider a more specific logger category name.

The logger resolution correctly uses ILoggerFactory to avoid the CS0718 error with static types. However, the generic category name "Hangfire" could be more specific to aid in log tracing.

Consider this alternative for better log attribution:

-        logger ??= app.ApplicationServices.GetService<ILoggerFactory>()?.CreateLogger("Hangfire");
+        logger ??= app.ApplicationServices.GetService<ILoggerFactory>()?.CreateLogger(nameof(HangfireExtensions));

Or use the fully qualified name:

-        logger ??= app.ApplicationServices.GetService<ILoggerFactory>()?.CreateLogger("Hangfire");
+        logger ??= app.ApplicationServices.GetService<ILoggerFactory>()?.CreateLogger(typeof(HangfireExtensions).FullName ?? nameof(HangfireExtensions));

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between def9151 and d5d681d.

📒 Files selected for processing (9)

• .github/actions/setup-postgres-connection/README.md (1 hunks)
• .github/actions/setup-postgres-connection/action.yml (1 hunks)
• .github/workflows/aspire-ci-cd.yml (2 hunks)
• .github/workflows/ci-cd.yml (2 hunks)
• .github/workflows/pr-validation.yml (3 hunks)
• docs/testing/test_infrastructure.md (1 hunks)
• infrastructure/test-database-init.sh (1 hunks)
• src/Shared/Jobs/HangfireExtensions.cs (2 hunks)
• tests/MeAjudaAi.Integration.Tests/Modules/Documents/DocumentsApiTests.cs (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (4)

• tests/MeAjudaAi.Integration.Tests/Modules/Documents/DocumentsApiTests.cs
• .github/workflows/aspire-ci-cd.yml
• .github/workflows/pr-validation.yml
• docs/testing/test_infrastructure.md

🧰 Additional context used

🧬 Code graph analysis (1)

src/Shared/Jobs/HangfireExtensions.cs (2)

src/Shared/Extensions/ServiceCollectionExtensions.cs (1)

• IApplicationBuilder (77-85)

src/Shared/Jobs/HangfireAuthorizationFilter.cs (1)

• HangfireAuthorizationFilter (10-37)

🪛 LanguageTool

.github/actions/setup-postgres-connection/README.md

[locale-violation] ~32-~32: “password” é um estrangeirismo. É preferível dizer “senha”.
Context: ...io do PostgreSQL | Não | postgres | | postgres-password | Senha do PostgreSQL | Não | `test123...

(PT_BARBARISMS_REPLACE_PASSWORD)

🪛 markdownlint-cli2 (0.18.1)

.github/actions/setup-postgres-connection/README.md

49-49: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ 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). (4)

• GitHub Check: Code Quality Checks
• GitHub Check: Security Scan
• GitHub Check: build-and-test
• GitHub Check: code-analysis

🔇 Additional comments (13)

infrastructure/test-database-init.sh (1)

55-55: Harden container name handling to avoid silent failures.

The container name meajudaai-postgres is hardcoded throughout the script (lines 55, 66, 109, 124, 149). If the service name in postgres.yml differs or Docker Compose generates a different container name in certain environments, health checks and database queries will silently fail to find the container.

Verify that postgres.yml consistently names the service as postgres to ensure the derived container name is always meajudaai-postgres. Alternatively, derive the container name dynamically:

# Extract container name from docker compose
CONTAINER_NAME=$(docker compose -f postgres.yml ps --quiet)
if [ -z "$CONTAINER_NAME" ]; then
    echo "❌ PostgreSQL container not found"
    exit 1
fi

# Then replace hardcoded references with $CONTAINER_NAME variable

Also applies to: 66-66, 109-109, 124-124, 149-149

.github/workflows/ci-cd.yml (3)

35-48: ✅ PostgreSQL service configuration looks solid.

The PostGIS-enabled image (postgis/postgis:16-3.4), health check pattern, and environment variable defaults are well-configured for testing. Port mapping is correct.

Verify that secrets (POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB) are defined in the repository secrets, or that the fallback defaults (test123, postgres, meajudaai_test) are acceptable for CI test runs.

---

65-73: ✅ Refactor to reusable action resolves prior duplication concerns.

The setup-postgres-connection action successfully centralizes connection string building, addressing the previous review comment about line length and code duplication across workflows.

Confirm that .github/workflows/aspire-ci-cd.yml and .github/workflows/pr-validation.yml also invoke this same action (to fully resolve duplication across all CI pipelines). If those files still contain inline connection string logic, they should be similarly refactored.

---

78-82: All 4 connection string keys reference the same output.

Lines 79–82 map the single action output to four distinct .NET configuration keys (ConnectionStrings__DefaultConnection, ConnectionStrings__Users, ConnectionStrings__Search, ConnectionStrings__meajudaai-db). Verify this is intentional for your .NET application structure.

Confirm that the .NET configuration deserializes all four keys from these environment variables, or if some are redundant and can be removed. If the application truly needs separate connections per module (Users, Search, etc.), verify they all point to the same PostgreSQL instance in tests, or if they should differ.

.github/actions/setup-postgres-connection/action.yml (2)

1-40: ✅ Action implementation is straightforward and correct.

The composite action cleanly encapsulates connection string building with sensible defaults, making it reusable across workflows. The Npgsql connection string format (Host;Port;Database;Username;Password) is correct.

---

20-23: Verify that default credentials are test-only.

The action defaults include plaintext test credentials (postgres, test123). Ensure these defaults are never accidentally used in production workflows by requiring explicit secret overrides for non-test environments.

Search the codebase to confirm that production or staging workflows explicitly override these defaults with strong, environment-specific credentials.

src/Shared/Jobs/HangfireExtensions.cs (7)

4-4: LGTM!

The Microsoft.Extensions.DependencyInjection using directive is necessary for the GetService<T>() extension method used later in the file.

---

19-27: LGTM!

The updated documentation accurately describes the defensive behavior added to the method, and the optional logger parameter provides flexibility for callers.

---

28-35: LGTM!

The early return when the dashboard is disabled is a good defensive programming pattern. The debug-level logging is appropriate and helps with troubleshooting without adding noise to production logs.

---

37-53: LGTM!

The runtime verification that Hangfire services are properly configured is excellent defensive programming. The try-catch block handles misconfiguration gracefully by logging warnings and exiting early, preventing potential runtime errors downstream.

---

58-70: LGTM!

The dashboard path validation and normalization logic is thorough and defensive. The warning logs help administrators identify and fix configuration issues, and the default values are sensible fallbacks.

---

72-77: LGTM!

The stats polling interval validation prevents invalid configurations and provides a sensible default. The warning logging helps administrators correct configuration issues.

---

78-86: LGTM!

The final dashboard configuration properly uses all validated and normalized values. The informational log provides useful operational visibility, and the authorization filter integration maintains security.

[github-actions]

📊 Code Coverage Report

Coverage: 40.51% (extracted from OpenCover (Direct))

📈 Coverage Details

• Coverage badges:
• Minimum threshold: 70% (warning) / 85% (good)
• Report format: Auto-detected from OpenCover/Cobertura XML files
• Coverage source: OpenCover (Direct)

📋 Coverage Analysis

• Line Coverage: Shows percentage of code lines executed during tests
• Branch Coverage: Shows percentage of code branches/conditions tested
• Complexity: Code complexity metrics for maintainability

🎯 Quality Gates

• ✅ Pass: Coverage ≥ 85%
• ⚠️ Warning: Coverage 70-84%
• ❌ Fail: Coverage < 70%

📁 Artifacts

• Coverage reports: Available in workflow artifacts
• Test results: TRX files with detailed test execution data

This comment is updated automatically on each push to track coverage trends.