GPT-5.6 Sol (xhigh) generated incorrect Rust decoding for a MySQL/MariaDB MAX() result

Environment

• Product: Codex CLI/TUI
• Codex CLI version: 0.149.1
• Model: gpt-5.6-sol
• Reasoning effort: xhigh
• Operating system: Windows
• Database: MySQL/MariaDB
• Language: Rust

What issue are you seeing?

GPT-5.6 Sol, running with xhigh reasoning effort, generated Rust code for a query equivalent to:

select max(integer_column) as max_value
from some_table

The generated code attempted to decode the result directly as i64, equivalent to:

let max_value = row.try_get::<i64, _>(max_value)?;

In the affected MySQL/MariaDB driver environment, the aggregate result was exposed as a DECIMAL-compatible value even though the source column was an integer. The generated Rust code compiled successfully but failed at runtime with a database type-decoding error.

This report is intentionally phrased in terms of the observed driver metadata rather than claiming that MAX() always returns DECIMAL; the exact mapping can depend on the server and Rust driver.

I first tried to submit this through the TUI feedback flow, but that submission failed with failed in TUI.

Steps to reproduce

1. Ask Codex using gpt-5.6-sol with xhigh reasoning to write Rust code that executes a MySQL/MariaDB query containing max(integer_column).
2. Use an environment in which the driver exposes the aggregate result as DECIMAL.
3. Decode the result directly as i64, as in the generated implementation.
4. Execute the query.
5. Observe that compilation succeeds but result decoding fails at runtime.

Expected behavior

Codex should not assume that the result type of an aggregate expression is identical to the source column type. It should account for the SQL dialect, server/driver type mapping, and aggregate nullability.

A safe implementation should either:

1. Decode the result using the driver's Decimal type and perform a checked conversion to i64, including fractional-value and overflow checks; or
2. Explicitly cast the result in SQL, for example:

select cast(max(integer_column) as signed) as max_value
from some_table

and decode it as Option<i64>. An unsigned cast should be used when appropriate.

The implementation should also account for MAX() returning NULL when there are no matching rows. A floating-point intermediate should generally be avoided because converting DECIMAL through f64 can lose precision.

Additional information

This failure is difficult to detect because the generated Rust code compiles and only fails when the query is executed. Since the model was running with xhigh reasoning effort, I expected it to verify the aggregate result type and the Rust driver's decoding rules before finalizing the implementation.

A useful regression evaluation would cover:

• MySQL and MariaDB aggregate-result metadata
• Rust database-driver type decoding
• DECIMAL-to-integer checked conversion
• Signed and unsigned integer columns
• NULL results from empty result sets
• Code that compiles successfully but fails during database decoding

Start with the reproduction for Codex CLI/TUI using gpt-5.6-sol and xhigh, then locate the Rust, MySQL/MariaDB, and aggregate-query evaluation paths. Verify how MAX() result metadata, DECIMAL conversion, signed and unsigned values, and NULL results are represented. Done means a regression evaluation catches code that compiles but fails during database decoding.