Support a bounded synchronous switchover deadline beyond 60 seconds

Open
  • Is something wrong?
#11,046 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #11045 by @weicao — closed without merging

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend-api-design, databases

Research direction

Start by tracing actionCallTimeoutContext and the synchronous caller's deadline checks; the issue identifies these as the relevant paths. Check how Ops and caller time budgets are compared before launch. Done means an explicitly configured switchover can use a bounded deadline up to 300 seconds, rejects insufficient time before launch, and waits for complete recovery rather than only the new primary role.

Written by the indexing model from the issue text.

Description

Related to #10297, but scoped specifically to bounded synchronous switchover. The general action-timeout policy requested there remains outside this change.

On revision 7129ad3, actionCallTimeoutContext caps positive action deadlines at 60 seconds even when the installed switchover action declares 300 seconds. Oracle DGMGRL may still need to restart the demoted primary before the addon can verify complete DG recovery. Retaining synchronous execution therefore requires a controlled longer action deadline and compatible caller/Ops budgets.

Expected for this scoped fix:

  • An explicitly configured switchover action may run for up to 300 seconds, while other action defaults/caps remain unchanged.
  • The caller remains synchronous, has a finite response deadline longer than execution, and rejects insufficient remaining Ops/caller time before launching.
  • The addon owns the complete recovery condition and does not return success merely because the new primary role is visible.

The paired addon recovery work is https://github.com/apecloud/apecloud-addons/pull/2373. KB implementation is #11045. This issue does not request unbounded execution, automatic retries after an unknown outcome, or a durable asynchronous protocol. No real Oracle CT of this candidate has been run yet.

Dominant language
Go
Stars
3.1k
Forks
282
Avg merge
1d 4h
Merged PRs (30d)
61

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apecloud/kubeblocks

All issues in apecloud/kubeblocks

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.