Fatal Failure Detection with Request Resources

[amir-aharon]

Overview

We propose writing an improvement to the provider. Before implementing, we want to hear your thoughts.
This proposal introduces a mechanism to detect fatal errors during CREATE or UPDATE actions in the Request resource. The goal is to avoid unnecessary remote API calls by Observe() after an unrecoverable error has already been detected.

Motivation

Currently, isUpToDate()—invoked by Observe()—uses JQ-based checks like expectedResponseCheck and isRemovedCheck to determine if a resource requires an update or has been removed. However, there's no mechanism to short-circuit further observations if a previous action (e.g., a bad request) has already failed irrecoverably.

By detecting such fatal failures, the controller can:

• Avoid redundant remote calls
• Prevent misleading status
• Surface errors that require manual intervention more clearly

---

Proposed Field: fatalFailureCheck

An optional JQ-based field under spec.forProvider, similar to existing checks:

fatalFailureCheck:
  type: CUSTOM
  logic: |
    if .response.statusCode == 400 
      and .response.body.error == "Invalid email format"
      then true 
      else false 
    end

Field Description

Field	Description
type	DEFAULT (same as today) or CUSTOM for user-defined JQ logic
logic	A JQ expression evaluated on the response of a CREATE or UPDATE request

If this logic returns true, the Request will be marked with a FatalFailure condition and future Observe() calls will skip the HTTP request.

---

Status Example

status:
  conditions:
    - type: Ready
      status: False
      reason: FatalFailure
      message: "Fatal error detected in Create response: Invalid email format"
    - type: FatalFailure
      status: True
      reason: FatalErrorDetected
      message: "Create response indicated fatal error per .spec.fatalFailureCheck"

---

Call Flow

[Create()/Update()]
   |
   |--> Send HTTP request
   |
   |--> Run `fatalFailureCheck.logic` if defined
         |
         |-- true  --> Set status.conditions["FatalFailure"]
         |-- false --> Continue normally
         
[Observe()]
   |
   |--> Check status.conditions["FatalFailure"]
         |
         |-- true  --> Skip HTTP call, return early
         |-- false --> Run isUpToDate()
                          |
                          |--> determineIfRemoved()
                          |--> determineIfUpToDate()

---

Benefits

• Reduces unnecessary HTTP calls for known-failure cases
• Clearly surfaces unrecoverable errors in resource status
• Aligns with existing, familiar configuration style (JQ logic)
• Fully optional and non-breaking for existing configurations

Thanks!

[arielsepton]

Hi 👋 @amir-aharon
Thanks for this proposal!

I really like the idea. It makes a lot of sense, and fits well with the current JQ-based checks.

One point to consider: how should users recover from a FatalFailure? Should changing the spec automatically remove the condition, or would they need to delete and recreate the resource?

Also, It could also help to support an optional reasonField to include a message from the response in the condition, so users can quickly see the failure reason.

fatalFailureCheck:
  type: CUSTOM
  logic: |
    if .response.statusCode == 400 and .response.body.error == "Invalid email format"
    then true else false end
  reasonField: .response.body.error

What do you think?

Overall, I’d be happy to approve it 🚀