Block resource creation when linked ResourceProvider not found in handle

[rhjcd]

Summary

• When linkedResourceProviders defines a waitFor condition and the linked resource is not found in the ResourceHandle, the manage() loop was silently skipping the check via continue in the for...else branch
• This allowed dependent resources (e.g., workload AnarchySubjects) to be created before their linked resources (e.g., cluster) were ready, causing provision failures
• Now blocks resource creation (wait_for_linked_provider = True) when the linked resource is missing and no when condition explains its absence
• Preserves existing behavior for linked providers with when conditions (conditional exclusion is expected)

Problem

ResourceProvider configs like:

linkedResourceProviders:
- name: cluster-provider
  waitFor: current_state_0 == 'started'
  templateVars:
  - name: current_state_0
    from: /spec/vars/current_state

...were not blocking the dependent resource. The workload provision fired immediately, failing with undefined variable errors because the cluster wasn't ready yet.

Root cause

In ResourceHandle.manage() (resourcehandle.py ~line 1356), the for...else block that searches for the linked resource in the handle hit the else branch and called continue, skipping to the next linked provider without setting wait_for_linked_provider = True.

Test plan

• Existing test-linked-01 through test-linked-03 pass (no regression)
• Manual test: create a multi-resource claim with waitFor on a linked provider, verify dependent resource shows waitingFor: "Linked ResourceProvider" until the linked resource is ready
• Verify when-conditioned linked providers still work correctly (test-linked-03)

Fixes RHDPOPS-23813.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: daeb3946-32ba-4b01-9a5e-c2b593f9d5cc

📥 Commits

Reviewing files that changed from the base of the PR and between 6a9633c and 6cfe3ca.

📒 Files selected for processing (1)

• operator/resourcehandle.py

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Improved handling of resources that depend on linked providers.
  • Resource creation now waits when a required linked provider is unavailable.
  • Providers with conditional requirements continue to be handled without blocking unrelated resource creation.

Walkthrough

ResourceHandle.manage now waits when an unconditional linked provider has no matching resource, while providers with a when condition continue to be skipped without blocking resource creation.

Changes

Linked provider handling

Layer / File(s)	Summary
Manage linked provider availability operator/resourcehandle.py	Missing unconditional linked providers set wait_for_linked_provider and stop processing; providers with a when condition log a debug message and allow processing to continue.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: jkupferer

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main behavior change: blocking creation when a linked ResourceProvider is missing.
Description check	✅ Passed	The description matches the code change and explains the missing linked provider wait behavior and its impact.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/linked-resource-provider-waitfor-bypass

---

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.}

[rhjcd]

Closing — further testing shows the waitFor mechanism works correctly on properly constructed claims. The original failure was caused by a different root cause (collection version pin).