fix(deployment): implement countByOwner method and corresponding tests

[baktun14]

Why

The deployments table at stats.akash.network/addresses/{address}/deployments shows "Page 1 of 1" even when an address has many deployments. The Cosmos SDK node returns an incorrect pagination.total value equal
to the page size (e.g. "10") instead of the true total count, resulting in pageCount = ceil(10/10) = 1 and making pagination navigation impossible.
https://stats.akash.network/addresses/akash10lq8uyfl52d6t467qmd58e7jzl9ecmvet2m57p/deployments

What

• Added countByOwner(owner, status?) method to DeploymentRepository that performs a fast COUNT query against the database, optionally filtering by active/closed status
• Modified DeploymentReaderService.listWithResources to use the DB count instead of the unreliable Cosmos SDK pagination.total
• Parallelized the lease fetch, provider list fetch, and DB count query with Promise.all for improved performance
• Set countTotal: false in the Cosmos SDK request since we no longer rely on its total
• Added unit tests for DeploymentRepository.countByOwner (3 tests) and DeploymentReaderService.listWithResources (7 tests)

Summary by CodeRabbit

• Tests

  • Added test suites for deployment counting and listing functionality with various status filters and pagination scenarios.

• Chores

  • Improved deployment data retrieval performance through concurrent request execution and optimized counting logic via database queries.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

This change adds a new countByOwner method to DeploymentRepository with optional status filtering for active or closed deployments, and refactors DeploymentReaderService to use this method. The service now fetches deployment counts from the database instead of HTTP pagination and parallelizes concurrent operations using Promise.all.

Changes

Cohort / File(s)	Summary
Repository Method Addition apps/api/src/deployment/repositories/deployment/deployment.repository.ts, apps/api/src/deployment/repositories/deployment/deployment.repository.spec.ts	Adds countByOwner(owner, status?) method that counts deployments by owner with optional filtering for active (closedHeight is null) or closed (closedHeight is not null) status. Includes comprehensive test suite verifying query generation for each status variant.
Service Refactoring apps/api/src/deployment/services/deployment-reader/deployment-reader.service.ts, apps/api/src/deployment/services/deployment-reader/deployment-reader.service.spec.ts	Injects DeploymentRepository, refactors listWithResources to use Promise.all for concurrent lease/provider/count fetching, sources deployment count from repository instead of HTTP pagination, and conditionally fetches providers only when deployments exist. Includes extensive test coverage for counting logic, status filtering, pagination handling, and provider fetch behavior.

Sequence Diagram

sequenceDiagram
    actor Client
    participant DRS as DeploymentReaderService
    participant HTTP as DeploymentHttpService
    participant LHS as LeaseHttpService
    participant Repo as DeploymentRepository
    participant DB as Database
    
    Client->>DRS: listWithResources(owner, status, skip, limit)
    
    Note over DRS: Setup Promise.all with 3 concurrent calls
    
    par Lease Fetch
        DRS->>LHS: getList(...)
        LHS-->>DRS: leaseList
    and Provider Fetch (if deployments exist)
        DRS->>HTTP: getList(...)
        HTTP-->>DRS: deploymentList
        alt deploymentList is not empty
            DRS->>HTTP: providers(...)
            HTTP-->>DRS: providerList
        end
    and Count Fetch
        DRS->>Repo: countByOwner(owner, status)
        Repo->>DB: Deployment.count(where clause)
        DB-->>Repo: count
        Repo-->>DRS: count
    end
    
    DRS->>DRS: Map deployments with owner/dseq
    DRS-->>Client: { deployments, count, leases, providers }

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A counting method hops into place,
While Promise.all picks up the pace!
No more sequential waiting in line—
Three concurrent calls align.
Count from the database, clean and precise,
This refactor's simply nice! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and clearly describes the main change: implementing a countByOwner method and its tests to fix deployment pagination.
Description check	✅ Passed	The description follows the template structure with complete Why and What sections that clearly explain the problem, solution, and implementation details.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/deployment-list-pagination

---

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

[codecov]

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

[ygrishajev]

I believe that requesting data from 1 source and pagination from another would cause another set of issues eventually. Switching entirely to the indexer is obviously not an option too due to performance issues.

Why can't this be fixed on the rpc node? Have this been requested to @akash-network/core ?