[DO NOT REVIEW YET] bump retry count upon task initialization as opposed to failure

[arthurpassos]

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Related to #1278

Documentation entry for user-facing changes

...

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• Tiered Storage (2h)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 201c0b76f3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use >= when enforcing retry cap

The new stale-state recovery check only trips when retry_count > max_retries, so a part that has already consumed its last allowed retry (e.g. a node crashes after incrementing retry_count but before handlePartExportFailure can mark FAILED) will still be re-attempted. That yields an extra export attempt beyond the configured export_merge_tree_partition_max_retries, and can lead to repeated retries if the same crash repeats. Using >= here (and in the analogous scheduler check) would keep behavior consistent with the failure handler’s >= limit and avoid exceeding the configured cap in this crash/pending scenario.

Useful? React with 👍 / 👎.