chore(wolf): checkpoint buglog.json (952 bugs)

This commit is contained in:
Rongsong Shen 2026-08-18 00:46:50 +00:00
parent f5390c14e2
commit fd5ab8b20d
Signed by: rshen
SSH key fingerprint: SHA256:8Vf2pZ3h6rJa7EhGK+WaAQ9Mta/apZvteW6g9U/WKKk

View file

@ -16211,8 +16211,8 @@
"related_bugs": [
"bug-1559"
],
"occurrences": 1,
"last_seen": "2026-08-15T22:54:35Z"
"occurrences": 2,
"last_seen": "2026-08-17T00:00:00.000Z"
},
{
"id": "bug-909",
@ -16316,7 +16316,7 @@
"bug-1470",
"bug-1553"
],
"occurrences": 3,
"occurrences": 4,
"last_seen": "2026-08-17T00:00:00.000Z"
},
{
@ -17018,6 +17018,25 @@
],
"occurrences": 1,
"last_seen": "2026-08-17T23:45:00Z"
},
{
"id": "bug-1571",
"timestamp": "2026-08-17T00:00:00.000Z",
"error_message": "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.",
"file": "src/tools/deploy-ha.sh",
"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!\".",
"tags": [
"apiserver",
"deploy-ha",
"xce-deploy-ha",
"backend-config",
"go",
"resource-value-verification"
],
"related_bugs": [],
"occurrences": 1,
"last_seen": "2026-08-17T00:00:00.000Z"
}
]
}