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 meshery/meshery#19254 , meshery/meshery#19227 , where it was suggested that the functionality should instead be abstracted into MeshKit for reuse across the ecosystem.
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 meshery/meshery#19254 , meshery/meshery#19227 , where it was suggested that the functionality should instead be abstracted into MeshKit for reuse across the ecosystem.