fix: `error_handling` Config Parsed but Never Used — Retry Settings Have No Effect

[pvandervelde]

Repository: pvandervelde/release_regent
Affects: All event processing (release PR merge, PR comment, PR activity)
Date: 2026-05-18

---

Summary

The [error_handling] config section (max_retries, backoff_multiplier,
initial_delay_ms) is fully defined in the config schema, merged correctly by the
config provider, and even appears in the lockable-fields list (meaning operators can
lock these values at the policy level). However, no retry loop anywhere in the core
processing code reads these values. All three settings are silently ignored at runtime.

---

Configuration (correct — not the cause)

[error_handling]
max_retries = 3
backoff_multiplier = 1.5
initial_delay_ms = 500

These keys map to ErrorHandlingConfig in crates/core/src/config.rs. They are
correctly parsed, stored, and supported by the config-merge and locking machinery. The
configuration is not the problem.

---

Root Cause

No retry logic exists in the core processing handlers

A search of the entire crates/ tree for references to
error_handling, max_retries, or backoff_multiplier outside of config definitions
and tests returns no results in lib.rs, release_automator.rs, or
release_orchestrator.rs. The event-processing functions (handle_release_pr_merged,
handle_pr_comment, handle_pull_request_merged, handle_pull_request_activity,
refresh_open_feature_pr_comments) call GitHub API operations directly with no retry
wrapper.

The config is present but has no consumer

ErrorHandlingConfig is:

• Defined in crates/core/src/config.rs
• Merged with lock support by crates/config_provider/src/github_provider.rs
• Listed in LOCKABLE_FIELDS (can be locked by policy operators)
• Tested in crates/core/src/config_tests.rs (default value assertions)

But it is never read in any event-processing path.

---

Impact

• GitHub API calls that fail transiently (rate-limit, 5xx) are not retried; the event
  is failed immediately.
• Users who configure max_retries expecting resilience against transient failures get
  no benefit.
• The inclusion of these fields in LOCKABLE_FIELDS implies they have policy-level
  significance, which is misleading while the feature is unimplemented.

---

What Needs to Be Built

This is not a simple "thread the config value through" fix. A retry mechanism needs to
be designed and implemented:

1. Define a retry helper (or select a crate such as tokio-retry) that accepts
   max_retries, backoff_multiplier, and initial_delay_ms.
2. Identify which GitHub API call categories are safe to retry (idempotent reads and
   creates-with-idempotency-key are safe; blind mutations may not be).
3. Wrap the retryable call sites in lib.rs (or at the GitHub client adapter layer).
4. Pass repo_config.error_handling into whichever struct owns the retry policy.

---

Files Likely to Change

• crates/core/src/lib.rs — add retry wrapping around GitHub API call sites
• crates/core/src/release_automator.rs — potentially add retry config field
• crates/core/src/release_orchestrator.rs — potentially add retry config field
• Cargo.toml — may need a retry crate dependency
• Tests — add tests that simulate transient failures and verify retry behaviour