Skip to content

docs: document Git backend unavailability behaviour and stale-cache fallback#3246

Open
won-seoop wants to merge 1 commit into
spring-cloud:mainfrom
won-seoop:doc-git-backend-unavailability
Open

docs: document Git backend unavailability behaviour and stale-cache fallback#3246
won-seoop wants to merge 1 commit into
spring-cloud:mainfrom
won-seoop:doc-git-backend-unavailability

Conversation

@won-seoop

Copy link
Copy Markdown

What

Closes #572.

Adds a new "Behavior When the Git Backend Is Unavailable" section to the Git Backend reference page.

Changes

A summary table covering four distinct scenarios:

Scenario Behaviour
No prior local clone + Git unreachable at first request Clone fails → HTTP 500
Git becomes unreachable after at least one successful clone/fetch Fetch fails silently (WARN log), server falls back to stale local clone → HTTP 200 with potentially outdated values
force-pull: true + Git unreachable Reset applied then fetch fails → no stale fallback → HTTP 500
cloneOnStart: true + Git unreachable at startup Server fails to start

Also includes a NOTE advising operators to monitor WARN log output and enable the Health Indicator, because the stale-cache fallback is completely transparent to clients.

Motivation

The existing docs explain cloneOnStart, force-pull, and refreshRate in isolation but do not describe what happens to clients when the remote Git server becomes unreachable at various points in the lifecycle. In particular the "stale fallback" path — where the server silently serves an older cached configuration — was completely undocumented and has confused many users.

🤖 Generated with Claude Code

…allback

Adds a new "Behavior When the Git Backend Is Unavailable" section to the
Git Backend reference page, addressing the scenarios raised in
spring-cloud#572.

The section covers four distinct scenarios in a summary table:
* Initial startup with no prior clone and an unreachable Git remote
* Transient remote outage after at least one successful clone/fetch
  (stale-cache fallback — previously undocumented)
* force-pull: true combined with an unreachable remote
* cloneOnStart: true when Git is unreachable at startup

Also adds a NOTE recommending that operators monitor WARN log output and
enable/alert on the Health Indicator, because the stale-cache fallback is
silent from a client perspective.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add docs for Config Server behavior when backend is not accessible

2 participants