Description
Fortify the LockCoordinator with infrastructure backoffs and best-effort cleanup logic. If the config-server returns 5xx infrastructure errors or network timeouts during lock acquisition, the SDK must back off exponentially (e.g., 1s, 2s, 4s, 8s) to protect the backend. Additionally, the final releaseLock execution within the cleanup block must silently swallow network errors, ensuring that transient cleanup failures do not crash the successfully updated Node process.
Acceptance criteria
Blocked by
Issue #126
User stories covered: 8, 9
Description
Fortify the LockCoordinator with infrastructure backoffs and best-effort cleanup logic. If the config-server returns 5xx infrastructure errors or network timeouts during lock acquisition, the SDK must back off exponentially (e.g., 1s, 2s, 4s, 8s) to protect the backend. Additionally, the final releaseLock execution within the cleanup block must silently swallow network errors, ensuring that transient cleanup failures do not crash the successfully updated Node process.
Acceptance criteria
Simulating a 5xx error or network timeout during lock acquisition triggers exponential backoff (verified via undici MockAgent and vi.useFakeTimers()).
Simulating a network error during the releaseLock call successfully catches and swallows the error without throwing an unhandled exception to the main Node process.
Blocked by
Issue #126
User stories covered: 8, 9