unclear behaviour of atomic timeout from documentation of helm CLI

[madbulgarianfromukraine]

The Issue

When using helm upgrade --install --atomic --timeout 5m:

• If the upgrade fails after 4 minutes
• The automatic rollback only has 1 minute remaining to complete
• If rollback doesn't finish in that 1 minute, it also fails

This behavior is not mentioned in the documentation, making it difficult to understand why rollbacks might fail or how to set appropriate timeouts.

Expected Behavior

Users should clearly understand that:

1. The timeout applies to the entire operation (upgrade + rollback combined)
2. Rollback does not get a fresh timeout period
3. Short timeouts with --atomic can cause rollback failures

Suggested Documentation Improvements

Option 1: Update --atomic description

--atomic If set, the upgrade process rolls back changes in case of failed upgrade.

Note: Rollback operations share the same timeout specified by --timeout.
If an upgrade fails after 4 minutes with --timeout 5m, the rollback must
complete within the remaining 1 minute. Consider using longer timeouts
with --atomic (e.g., --timeout 10m).

Option 2: Update --timeout description

--timeout duration Time to wait for Kubernetes operations (default 5m0s).

When used with --atomic, this timeout applies to the entire operation
including both upgrade and rollback. Example: with --timeout 5m, if
upgrade takes 4m then fails, rollback has 1m remaining.

Additional Context

This behavior can be verified in the source code at pkg/action/upgrade.go where the timeout context is created once and shared across both upgrade and rollback operations.

[TerryHowe]

The --atomic option is deprecated in v4, so you might need to update for that unless this is a v3 only issue.