HDDS-12708. Fix Unhealthy Containers API for pagination

[ArafatKhan2198]

What changes were proposed in this pull request?

Problem Statement

The unhealthy containers API had broken pagination - it only supported forward navigation, making it impossible for users to go back to previous pages without starting over from the beginning.

Root Cause

• Single parameter limitation: Only prevKey parameter for forward pagination
• No backward navigation: Users could only click "Next", never "Previous"
• Poor UX: Browsing large datasets (1000+ containers) became frustrating
• API inconsistency: Lagged behind other paginated endpoints in the system

Solution Implemented

Added bidirectional pagination with two new parameters:

New Parameters:

• maxContainerId - for backward pagination (Previous button)
• minContainerId - for forward pagination (Next button)

Technical Changes:

1. Database query logic updated to handle both directions
2. Parameter validation for both forward and backward navigation
3. Response structure enhanced with proper firstKey/lastKey for pagination
4. Documentation improved with clear usage examples

Before vs After

Before (Broken):

GET /unhealthy?limit=3&prevKey=6
# Only forward navigation possible
# No way to go back to previous pages

After (Fixed):

# Forward pagination
GET /unhealthy?limit=3&minContainerId=6
# Returns: [7, 8, 9]

# Backward pagination  
GET /unhealthy?limit=3&maxContainerId=6
# Returns: [3, 4, 5]

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-12708

How was this patch tested?

Bidirectional Pagination Test Report for Unhealthy Containers API

Initial Dataset Overview

Total Missing Containers: 9 containers
Container IDs in ascending order: [2, 4, 6, 8, 12, 14, 16, 18, 20]

---

Test Results

Test 1: First Page (Baseline)

Endpoint: GET http://localhost:9888/api/v1/containers/unhealthy/MISSING?limit=3

Response Summary:

• Container IDs: [2, 4, 6]
• firstKey: 2
• lastKey: 6
• Status: ✅ PASS - Correctly returns first 3 containers

---

Test 2: Forward Pagination (Next Page)

Endpoint: GET http://localhost:9888/api/v1/containers/unhealthy/MISSING?limit=3&minContainerId=6

Response Summary:

• Container IDs: [8, 12, 14]
• firstKey: 8
• lastKey: 14
• Status: ✅ PASS - Correctly returns next 3 containers after ID 6

---

Test 3: Forward Pagination (Next Page)

Endpoint: GET http://localhost:9888/api/v1/containers/unhealthy/MISSING?limit=3&minContainerId=14

Response Summary:

• Container IDs: [16, 18, 20]
• firstKey: 16
• lastKey: 20
• Status: ✅ PASS - Correctly returns next 3 containers after ID 14

---

Test 4: Backward Pagination (Previous Page)

Endpoint: GET http://localhost:9888/api/v1/containers/unhealthy/MISSING?limit=3&maxContainerId=16

Response Summary:

• Container IDs: [8, 12, 14]
• firstKey: 8
• lastKey: 14
• Status: ✅ PASS - Correctly returns previous 3 containers before ID 16

---

Navigation Flow Verification

Forward Navigation Sequence:

1. Page 1: [2, 4, 6] ✅
2. Page 2: [8, 12, 14] ✅ (using minContainerId=6)
3. Page 3: [16, 18, 20] ✅ (using minContainerId=14)

Backward Navigation Sequence:

1. From Page 3: [16, 18, 20]
2. Back to Page 2: [8, 12, 14] ✅ (using maxContainerId=16)
3. Back to Page 1: [2, 4, 6] ✅ (using maxContainerId=8)

---

Conclusion

✅ BIDIRECTIONAL PAGINATION IS WORKING CORRECTLY

The API successfully demonstrates:

• Forward pagination using minContainerId parameter
• Backward pagination using maxContainerId parameter
• Consistent navigation between pages in both directions
• Proper handling of non-sequential container IDs
• Accurate response structure with correct firstKey and lastKey values

The implementation successfully addresses the original problem of limited pagination support and now provides full bidirectional navigation capabilities for the unhealthy containers API.

[devmadhuu]

Thanks @ArafatKhan2198 for the patch. Few nits.

[devmadhuu]

Thanks @ArafatKhan2198 for the patch. Current impl looks good. But can you pls update the problem or issue with existing current implementation in your PR description ?

[ArafatKhan2198]

Thanks @ArafatKhan2198 for the patch. Current impl looks good. But can you pls update the problem or issue with existing current implementation in your PR description ?

What was the problem earlier?

The unhealthy containers API had broken pagination - it only worked in one direction (forward).

The issue:

• Users could only click "Next" to see more containers
• There was no way to go back to previous pages
• If you were on page 3 and wanted to see page 2, you had to start over from the beginning
• This made the UI unusable for browsing large lists of unhealthy containers

Why this was bad:

• Poor user experience - imagine trying to browse through 1000+ unhealthy containers
• Inconsistent with other APIs that had proper pagination
• Made the Recon UI containers page frustrating to use

How did we solve it?

We added bidirectional pagination by introducing two new parameters:

1. maxContainerId - for going backwards (Previous button)
2. minContainerId - for going forwards (Next button)

Explanation with Example:

Before (broken):

GET /unhealthy?limit=3&prevKey=6

• Only could get containers with ID > 6
• No way to get containers with ID < 6
• Users stuck going only forward

After (fixed):

# Forward pagination (Next button)
GET /unhealthy?limit=3&minContainerId=6
# Returns containers with ID > 6: [7, 8, 9]

# Backward pagination (Previous button)
GET /unhealthy?limit=3&maxContainerId=6
# Returns containers with ID < 6: [3, 4, 5]

Real-world scenario:

• You have 1000 unhealthy containers: [1, 2, 3, ..., 1000]
• You're viewing containers [7, 8, 9] (page 3)
• Before: Could only go to [10, 11, 12] (page 4), couldn't go back to [4, 5, 6] (page 2)
• After: Can go both ways - to [10, 11, 12] OR back to [4, 5, 6]

The fix:

• Updated the database query logic to handle both directions
• Added proper documentation explaining how to use each parameter
• Made the API consistent with other paginated endpoints

Result:

• Users can now navigate both forward and backward through unhealthy containers
• UI can have proper "Previous" and "Next" buttons
• Much better user experience for browsing large datasets

In simple terms: We fixed the pagination so users can go both ways instead of being stuck going only forward.

[devmadhuu]

Thanks @ArafatKhan2198 for the patch. Current impl looks good. But can you pls update the problem or issue with existing current implementation in your PR description ?

What was the problem earlier?

The unhealthy containers API had broken pagination - it only worked in one direction (forward).

The issue:

* Users could only click "Next" to see more containers

* There was no way to go back to previous pages

* If you were on page 3 and wanted to see page 2, you had to start over from the beginning

* This made the UI unusable for browsing large lists of unhealthy containers

Why this was bad:

* Poor user experience - imagine trying to browse through 1000+ unhealthy containers

* Inconsistent with other APIs that had proper pagination

* Made the Recon UI containers page frustrating to use

How did we solve it?

We added bidirectional pagination by introducing two new parameters:

1. **`maxContainerId`** - for going backwards (Previous button)

2. **`minContainerId`** - for going forwards (Next button)

Explanation with Example:

Before (broken):

GET /unhealthy?limit=3&prevKey=6

* Only could get containers with ID > 6

* No way to get containers with ID < 6

* Users stuck going only forward

After (fixed):

# Forward pagination (Next button)
GET /unhealthy?limit=3&minContainerId=6
# Returns containers with ID > 6: [7, 8, 9]

# Backward pagination (Previous button)
GET /unhealthy?limit=3&maxContainerId=6
# Returns containers with ID < 6: [3, 4, 5]

Real-world scenario:

* You have 1000 unhealthy containers: [1, 2, 3, ..., 1000]

* You're viewing containers [7, 8, 9] (page 3)

* **Before:** Could only go to [10, 11, 12] (page 4), couldn't go back to [4, 5, 6] (page 2)

* **After:** Can go both ways - to [10, 11, 12] OR back to [4, 5, 6]

The fix:

* Updated the database query logic to handle both directions

* Added proper documentation explaining how to use each parameter

* Made the API consistent with other paginated endpoints

Result:

* Users can now navigate both forward and backward through unhealthy containers

* UI can have proper "Previous" and "Next" buttons

* Much better user experience for browsing large datasets

In simple terms: We fixed the pagination so users can go both ways instead of being stuck going only forward.

Pls update the same in PR description with UI screenshot.

[devmadhuu]

@ArafatKhan2198 Thanks for API testing and providing explanation. Kindly put the same in PR description , what was the issue in previous approach and what we are fixing in this PR. If you want, you can remove from comments, Also kindly mention the UI change PR for this backend change, here , so that there is clarity.

[devmadhuu]

Also changing the API signature where we don't have now default batch number, can you test with existing UI code ?

[devabhishekpal]

Thanks @ArafatKhan2198 for this patch.
LGTM, +1

[ArafatKhan2198]

Patch for the UI changes - #8862
cc: @devabhishekpal @devmadhuu

[devmadhuu]

Patch for the UI changes - #8862 cc: @devabhishekpal @devmadhuu

Thanks @ArafatKhan2198 for the revised changes and thanks @devabhishekpal for the review. Changes LGTM +1