**Affected version:** 7.12 - 7.17.7, 8.0-8.5
**Fixed in:** 7.17.7, 8.5.0

### Problem Description

A continuous transform can fail if a transform is searching at the same time as an ILM action occurs or in general anything that closes an index. This should not happen if transform is configured with a wildcard pattern for the source index, e.g. `filebeat-*`.

In a specific case an ILM policy temporarily closes the index due to the unfollow-the-follower action.

A typical log entry for this bugs contains something like this:

```
task encountered irrecoverable failure: org.elasticsearch.cluster.block.ClusterBlockException: index [ ... ] blocked by: [FORBIDDEN/4/index closed];
```

### Mitigation

A: Restart the transform. This can be automated by monitoring `_stats` and restarting the transform using `_stop?force=true` followed by `_start`.

B: Don't use the ILM unfollow action until a fix is available.

C: **Unreleased**: Starting with 8.5 set the transform to `unattended` mode via `settings`, this will let transform retry even for this failure class

### Solution

If the source of a transform is configured with a wildcard, transform should not treat an index closed exception as an irrecoverable failure.

### Backport

The fix needs to be backported to the `7.17` series.
x-pack/plugin/transform/src/main/java/org/elasticsearch/xpack/transform/transforms/TransformFailureHandler.java
}
    }
    /**
     * Terminate failure handling by failing the transform.
     * <p>
     * This should be called if the transform does not run unattended and the failure is permanent or after the
     * configured number of retries.
     *
     * @param failureMessage the reason of the failure
     */
    private void fail(String failureMessage) {
        
        context.markAsFailed(failureMessage);
    }
    /**
     * Get the number of retries.
     * <p>
     * The number of retries are read from the config or if not read from the context which is based on a cluster wide
     * default. If the transform runs in unattended mode, the number of retries is always indefinite.
     *
     * @param settingsConfig the setting config
     * @return the number of retries or -1 if retries are indefinite
     */
    private int getNumFailureRetries(SettingsConfig settingsConfig) {
        return Boolean.TRUE.equals(settingsConfig.getUnattended())
            ? -1
            : Optional.ofNullable(settingsConfig.getNumFailureRetries()).orElse(context.getNumFailureRetries());
    }
}