Generator fabricates list-response JSON wrapper tags from parseSingular(), causing recurring silent-nil-slice bugs
- 主要言語
- Go
- スター
- 39
- フォーク
- 47
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
Splitting this out as the systemic root cause behind a recurring class of bugs (#135, #136 / #137, and the four just fixed in #154).
### Problem
For `ListResponse` structs, `generate.go` derives the JSON wrapper tag from `strings.ToLower(parseSingular(listName))`. But the key CloudStack actually returns is set server-side via `setObjectName(...)`, and it is frequently **not** what `parseSingular` produces:
- camelCase: `listHypervisorCapabilities` → server `hypervisorCapabilities`, generator `hypervisorcapability`
- `-xes` plural: `…Ipv6Prefixes` → `Prefixe` (also corrupts the element **type name**), server `guestnetworkipv6prefix`
- hand-chosen keys: `listLBHealthCheckPolicies` → server `healthcheckpolicies` (drops the `lb`, stays plural), generator `lbhealthcheckpolicy`
When the tag is wrong, `json.Unmarshal` populates `Count` but leaves the slice **nil** — silent data loss — and the generated `GetByID` helper then panics on `slice[0]`.
### Current mitigation doesn’t scale
`generateResponseType` already carries a hand-maintained override `switch` (~30 cases, incl. the metrics ones) that exists precisely to patch this. Each new case is added **reactively**, only after a user hits a nil slice. #154 adds four more; there are almost certainly others not yet reported.
Note: `listApis.json` (the generator input) does **not** expose the list wrapper object name — it carries each item’s `response` fields and `related`, but not the `setObjectName` value — so the correct key can’t simply be read from there.
### Proposed directions
1. **Harden `parseSingular`** for the regular English plurals it currently mishandles — `-xes/-ses/-ches/-shes` → drop `es` (it already does `-ies`/`-sses`). This fixes the `Prefixe` type-name corruption and several tags for free, shrinking the override set.
2. **Make the override set verifiable instead of reactive:** add a CI/test check that asserts each `ListResponse` tag against the keys in the `test/testdata/*.json` fixtures (and/or a captured real response), so drift is caught at build time rather than by users in production.
3. Optionally, a curated `command → objectName` override map (cleaner than inline `switch` cases) seeded from the verified keys.
I verified the #154 keys against the CloudStack server source (`setObjectName`) and have a 4.22 environment; happy to take on (1) and/or (2) if a maintainer signals a preferred direction.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
generate.go、特に parseSingular と generateResponseType から始め、既存の override switch を確認してください。生成された ListResponse の tags を test/testdata/*.json の検証済みキーおよびサーバー側の setObjectName の値と比較してください。listApis.json にはそれらの wrapper 名は含まれていません。提案した複数形の処理および/または検証方法によって、reactive override だけに依存せず、nil slice が黙って発生することを防げれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- go
- 領域
- api, tooling
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100