fix(apiform): preserve float32 precision in comma arrays

[sylvesterkaczmarek]

Summary

Keep multipart comma-array float32 serialization consistent with the existing scalar float32 path.

Fixes #77.

Problem

internal/apiform already formats scalar float32 values with 32-bit precision, but FormatComma arrays combine float32 and float64 behind a 64-bit formatting call.

That means the same source value can be represented differently depending only on whether it appears by itself or inside a comma-delimited form field.

For example, current main serializes:

float32(0.1)

as:

0.1

but:

[]float32{0.1, 1.5}

with FormatComma as:

0.10000000149011612,1.5

Root cause

The primitive form path correctly distinguishes widths:

case reflect.Float32:
    strconv.FormatFloat(val.Float(), 'f', -1, 32)
case reflect.Float64:
    strconv.FormatFloat(val.Float(), 'f', -1, 64)

The comma-array path instead uses one branch for both kinds and always passes bitSize=64. Reflection returns floating-point values as float64, so the 64-bit formatting request preserves digits introduced by widening the original float32.

Fix

Split the comma-array branch by source kind:

• reflect.Float32 -> FormatFloat(..., 32)
• reflect.Float64 -> FormatFloat(..., 64)

No multipart boundaries, field names, array-format selection, integer formatting, boolean formatting, or float64 output changes.

Regression coverage

The existing table-driven form encoder test now includes:

• a scalar float32(0.1) control showing the existing expected representation;
• a FormatComma []float32{0.1, 1.5} regression requiring 0.1,1.5.

The comma-array case fails on current upstream main, while the scalar control demonstrates the consistency requirement directly.

Validation

The branch is based directly on upstream main at d082a010f7c6cacf407d8a1581446a7857f9f1bb and is not behind it.

Production diff: 3 additions and 1 deletion in internal/apiform/encoder.go, plus focused table-driven coverage in internal/apiform/form_test.go.

Full repository validation is left to the repository's GitHub Actions checks.

Risk

Low. Only the textual formatting of float32 values inside FormatComma arrays changes, and it becomes identical to the width-aware behavior already used for scalar float32 fields. float64 and all non-floating form values are unchanged.

[markstuart-oai]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-15T16:33:56.815510Z	66a37a9	New commits
🔒 Security Review	✅ Completed 2026-09-15T16:34:33.230914Z	66a37a9	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: b686484b73

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Security review completed. No security issues were found in this pull request.

Reviewed commit: b686484b73

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[saioai]

#119 merged the same float32 formatting fix, and i ran your two float32 cases against current main with the race detector; they pass.

[saioai]

i checked #78 against current main. #119 already merged the float32 fix, so this adds just the two missing tests. the comma case failed before the fix and passes now; local race and apiform tests passed

[github-actions]

Castiron custom code

✅ No new custom-code files detected.

5 mixed files remain; 0 existing customizations changed.

Compared 9d146cd3dfd5 → 66a37a99ce5f. Generated baselines verified.

5 existing customizations unchanged

• pkg/cmd/adminorganizationcertificate.go
• pkg/cmd/cmd.go
• scripts/castiron/README.md
• scripts/castiron/custom_code_report.py
• scripts/castiron/test_custom_code_report.py

A changed generated baseline means this report cannot reliably identify which handwritten lines changed.

Inspect the custom-code diff

Download the exact patch produced by this run (requires repository access):

gh run download 34995597458 --repo openai/openai-cli \
  --name castiron-custom-code-34995597458-1 --dir /tmp/castiron-custom-code-34995597458-1
git apply --stat /tmp/castiron-custom-code-34995597458-1/custom-code.patch
cat /tmp/castiron-custom-code-34995597458-1/custom-code.patch

Or reproduce it from an SDK checkout containing the vendored reporter:

git fetch --no-tags origin 9d146cd3dfd56fec12156b8621ebe581bd4bbe62 66a37a99ce5f44c1b1f2e86fa71bfc3ee4bb0684
python3 scripts/castiron/custom_code_report.py report \
  --base 9d146cd3dfd56fec12156b8621ebe581bd4bbe62 \
  --head 66a37a99ce5f44c1b1f2e86fa71bfc3ee4bb0684 --fetch --require-head-hash --public \
  --out /tmp/castiron-custom-code-66a37a99ce5f
cat /tmp/castiron-custom-code-66a37a99ce5f/custom-code.patch

This is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR.

Full report and patch

[sylvesterkaczmarek]

Thanks for checking this against current main and keeping the two regression cases. Glad the tests could still land after #119 covered the implementation.