Aleksandr Sarantsev f0c0733a64 storcon: Ignore stuck reconciles when considering optimizations (#12589) ...

## Problem

The `keep_failing_reconciles` counter was introduced in #12391, but
there is a special case:

> if a reconciliation loop claims to have succeeded, but maybe_reconcile
still thinks the tenant is in need of reconciliation, then that's a
probable bug and we should activate a similar backoff to prevent
flapping.

This PR redefines "flapping" to include not just repeated failures, but
also consecutive reconciliations of any kind (success or failure).

## Summary of Changes

- Replace `keep_failing_reconciles` with a new `stuck_reconciles` metric
- Replace `MAX_CONSECUTIVE_RECONCILIATION_ERRORS` with
`MAX_CONSECUTIVE_RECONCILES`, and increasing that from 5 to 10
- Increment the consecutive reconciles counter for all reconciles, not
just failures
- Reset the counter in `reconcile_all` when no reconcile is needed for a
shard
- Improve and fix the related test

---------

Co-authored-by: Aleksandr Sarantsev <aleksandr.sarantsev@databricks.com>

2025-07-17 14:52:57 +00:00

..

client

storcon + safekeeper + scrubber: propagate root CA certs everywhere (#11418)

2025-04-04 06:30:48 +00:00

migrations

Add new activating scheduling policy for safekeepers (#12441)

2025-07-03 16:27:43 +00:00

src

storcon: Ignore stuck reconciles when considering optimizations (#12589)

2025-07-17 14:52:57 +00:00

Cargo.toml

A few SC changes (#12615)

2025-07-17 13:14:36 +00:00