Explain the execution flow when a fallback method itself throws an exception?

If the fallback method itself throws, Resilience4j doesn't retry the fallback or fall back to a "fallback of the fallback" automatically - the exception thrown by the fallback simply propagates to the caller as-is, since fallback logic is treated as ordinary application code once control reaches it.

With Spring's declarative fallbackMethod attribute, this means the exception surfaces exactly as if the fallback method had been called directly and thrown - there's no special wrapping or suppression layered on top by the framework.

Chained fallbacks are possible, but they have to be built explicitly - either a second fallbackMethod attribute chained via multiple annotations, or, with the functional API, multiple .recover(...) calls stacked so a later one catches whatever the earlier one's fallback might throw.

This is a common source of confusing production incidents: a team adds a fallback assuming it's guaranteed to produce a safe result, without realizing that a bug in the fallback itself - a null pointer, a bad cast - will surface as an unhandled exception exactly like the original failure would have.