HYPERFLEET-608 - fix: Store first adapter status report with Available=Unknown

[rafabene]

Summary

• First status report from an adapter is now stored even when Available=Unknown, so users can see adapter status in the cluster/statuses endpoint while validation is still in progress
• Subsequent status reports with Available=Unknown continue to be discarded (existing behavior preserved)
• Aggregation is skipped for first Unknown reports to avoid affecting cluster/nodepool synthetic conditions

Changes

• pkg/services/cluster.go: Modified ProcessAdapterStatus to allow first Unknown report
• pkg/services/node_pool.go: Same change applied for nodepool
• pkg/services/cluster_test.go: Updated and added tests (4 new test cases)
• pkg/services/node_pool_test.go: Updated and added tests (4 new test cases)

Test plan

• Unit tests pass (383 tests)
• Lint passes (0 issues)
• Verify first adapter status with Available=Unknown returns HTTP 201 and is stored
• Verify subsequent adapter status with Available=Unknown returns HTTP 204 and is discarded
• Verify adapter status with Available=True or Available=False still works as before
• Verify cluster/nodepool synthetic conditions are not affected by first Unknown report

Fixes: HYPERFLEET-608

Summary by CodeRabbit

• Tests

  • Expanded coverage for adapter status handling, verifying that first "Unknown" availability reports are stored and subsequent identical reports are treated as no-ops.

• Chores

  • Refined adapter-status processing so first "Unknown" reports are recorded (created) while later "Unknown" reports are ignored (no-op), and aggregation is skipped when appropriate.

[coderabbitai]

Walkthrough

The PR changes adapter-status handling for cluster and node-pool services: when an adapter reports Available=Unknown, the first such report is upserted but aggregation is intentionally skipped; subsequent Unknown reports are treated as no-ops (discarded). Tests and integration tests were updated/added to assert first-report storage (HTTP 201) and subsequent no-op behavior (HTTP 204). No public APIs or function signatures were changed.

Sequence Diagram(s)

sequenceDiagram
    participant Adapter
    participant Service
    participant DAO as "DAO/Database"
    participant Aggregator

    Note over Adapter,Service: First report with Available=Unknown
    Adapter->>Service: POST adapter status (Available=Unknown)
    Service->>DAO: Lookup existing adapter status
    DAO-->>Service: Not found
    Service->>DAO: Upsert adapter status (store)
    DAO-->>Service: Upsert OK
    Service--xAggregator: (skip aggregation) 
    Service-->>Adapter: HTTP 201 Created

    Note over Adapter,Service: Subsequent report with Available=Unknown
    Adapter->>Service: POST adapter status (Available=Unknown)
    Service->>DAO: Lookup existing adapter status
    DAO-->>Service: Found
    Service-->>DAO: No-op (discard)
    Service-->>Adapter: HTTP 204 No Content

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat: implement Kubernetes-style status semantics and generation tracking #4 — Changes to ProcessAdapterStatus addressing first-vs-subsequent Available=Unknown behavior and aggregation skipping; directly touches the same aggregation logic.

Suggested labels

lgtm, approved

Suggested reviewers

• ciaranRoche
• aredenba-rh

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically summarizes the main change: storing the first adapter status report when Available=Unknown, which is the primary behavioral fix across cluster and nodepool services.
Docstring Coverage	✅ Passed	Docstring coverage is 87.50% which is sufficient. The required threshold is 80.00%.

_{✏️ 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

---

No actionable comments were generated in the recent review. 🎉

---

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

[rafabene]

/retest

[rh-amarin]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rh-amarin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rh-amarin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment