Feature Request: Centralized Retry/Backoff Helper in MeshKit

@Pranav-d33 is already working on this.

Since Jun 18, 2026.

Current Situation
Retry and backoff logic across Meshery components is currently implemented in an ad hoc, per-call-site manner. This can lead to:

duplicated retry implementations
inconsistent retry policies and backoff strategies
fragmented observability/logging behavior
harder long-term maintenance
During discussion in a related PR, it was noted that Meshery does not yet have a standardized retry/backoff abstraction.

Existing Precedent
A reusable retry pattern already exists in parts of the ecosystem, for example in meshery-adapter-library, which uses cenkalti/backoff/v4 in adapter/meshmodel.go.

This suggests an opportunity to move toward a shared abstraction in MeshKit, which is already a common dependency across Meshery components.

Proposal
Introduce a centralized retry/backoff helper in MeshKit that can be reused across Meshery projects.

Potential goals:

standardized retry behavior
configurable backoff strategies
reusable helper APIs instead of hand-rolled retry loops
improved consistency across components
centralized observability/logging hooks
easier future maintenance and tuning
Possible Scope
Initial implementation could focus on:

exponential backoff support
configurable retry counts/durations
retry conditions based on error types
context-aware cancellation support
lightweight and composable API surface
Non-Goals (Initial Version)
workflow orchestration
distributed retry coordination
persistence/stateful retry queues
Related Discussion
This issue originates from discussion around introducing retry logic in a component-specific PR https://github.com/meshery/meshery/pull/19254 , https://github.com/meshery/meshery/pull/19227 , where it was suggested that the functionality should instead be abstracted into MeshKit for reuse across the ecosystem.