---
id: "bug-1571"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "build"
severity: "unknown"
timestamp: "2026-08-17T00:00:00.000Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/tools/deploy-ha.sh"]
tags: ["apiserver", "deploy-ha", "xce-deploy-ha", "backend-config", "go", "resource-value-verification"]
related: []
legacy: true
---

# bug-1571: apiserver logs "Backend not configured -- running in stub mode" and never calls RegisterToBackend…

## Description
apiserver logs "Backend not configured -- running in stub mode" and never calls RegisterToBackend, even though the generated app.yaml backend.peers list is fully populated with a valid HA candidate list.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
resource-value-verification task 3.1 (xce-deploy-ha apiserver step): the new deploy-ha.sh Step-3 apiserver-config generation block initially wrote backend.address: "" and backend.port: 0 in the generated app.yaml, reasoning that backend.peers (non-empty) takes priority over address/port inside RegisterToBackend per backend/config.go's own doc comment. That reasoning only covers WHICH candidate RegisterToBackend picks once called -- it does not cover WHETHER it is called at all. apiserver/cmd/main.go:58 gates the entire RegisterToBackend call behind `BackendYamlConfig.Address != ""`, checked before Peers is ever consulted. A blank address left the apiserver permanently in stub mode regardless of a fully-populated peers list. Caught live during this task's own scenario-B verification run (grep of apiserver.log showed the stub-mode line instead of the expected "Backend connection established").

## Fix
deploy-ha.sh's apiserver app.yaml generation now also populates backend.address/backend.port from the first --peers candidate (host/port split via bash parameter expansion) alongside the full backend.peers list, so main.go's gate passes and RegisterToBackend still uses the full peers candidate list for actual connection/failover. Re-verified live: apiserver.log now shows "Attempting backend connection" / "Backend connection established" / "Backend connection registered!".

## Verification
_Not recorded (migrated from buglog.json)._

## References
_Not recorded (migrated from buglog.json)._