Cover postgres_instance_config_post + postgres_instance_config_patch

[sdairs]

Summary

postgres_instance_config_post and postgres_instance_config_patch have no live coverage. The existing postgres test explicitly defers this (see comment in tests/integration_postgres_test.rs Runtime Config phase) because PgConfig has non-Option serde_json::Value fields that serialize as null, which the live API rejects with Validation failed for following fields: pg_config.*.

Blocker

Either:

• OpenAPI spec marks the relevant fields as optional / nullable, and update-models-optionality.py regenerates them as Option<Value>; or
• The generator emits Option<Value> regardless.

Either path requires a fix upstream of this test issue.

Scope (once unblocked)

Extend tests/integration_postgres_test.rs Runtime Config phase:

• postgres_instance_config_post — set an initial config (e.g. max_connections).
• postgres_instance_config_get — confirm the change is visible.
• postgres_instance_config_patch — change max_connections to another valid value.
• postgres_instance_config_get — confirm the patched value.
• Optionally restore the original.

Where this lands

• crates/clickhouse-cloud-api/tests/integration_postgres_test.rs

Parent: #151

[sdairs]

Status: still blocked

Re-checked the spec + generated models against the latest clickhouse_cloud_openapi.json. The underlying bug has not been fixed upstream; the integration phase still cannot be unblocked without either a spec fix or a local optionality exemption.

Findings

pgConfig schema (components.schemas.pgConfig, line ~21427)

• Lists 22 properties (max_connections, default_transaction_isolation, maintenance_work_mem, …, wal_compression).
• No required array. None of the property descriptions start with the word Optional.
• Under our resolver's GA/legacy convention (no required array → fields without Optional description are required) every property is treated as required.
• additionalProperties: false, minProperties: 1 — spec intent is clearly "pick any non-empty subset", i.e. each individual property is optional.

Generated PgConfig in src/models.rs:11209

Direct consequence: every field is a bare type, not Option<T>:

pub struct PgConfig {
    pub default_transaction_isolation: PgConfigDefaultTransactionIsolation,  // enum, defaults to first variant
    pub effective_cache_size: serde_json::Value,                              // null when default
    pub effective_io_concurrency: i64,                                         // 0 when default
    pub idle_in_transaction_session_timeout: serde_json::Value,                // null
    pub idle_session_timeout: serde_json::Value,                               // null
    pub lock_timeout: serde_json::Value,                                       // null
    pub maintenance_work_mem: serde_json::Value,                               // null
    pub max_connections: i64,                                                  // 0
    // … 14 more fields, 14 of which are `serde_json::Value` because the spec
    // declares `type: ["string","integer"]` for the size/time params.
}

Serialising PgConfig { max_connections: 200, ..Default::default() } produces a body where all the serde_json::Value fields serialise as null and the i64/f64/enum fields go out as zero or first-variant — every one of which the live API rejects with Validation failed for following fields: pg_config.* (this is the exact failure the deferred test comment in tests/integration_postgres_test.rs already documents).

pgBouncerConfig (line ~21685)

Free-form map (additionalProperties: { type: string }, minProperties: 1, maxProperties: 64). Generated as an empty struct pub struct PgBouncerConfig {}. The wrapping postgresInstanceConfig schema marks pgBouncerConfig as required, so any POST/PATCH must include it, but the empty struct serialises to {} which fails minProperties: 1. There's no way to express "patch only pgConfig" from the current models.

postgresInstanceConfig request body (line ~22214)

{ "required": ["pgConfig", "pgBouncerConfig"] }

Forces callers to include both top-level keys even for a PATCH that only touches one. Combined with the issues above this means there is currently no callable shape from Rust that the live API accepts.

OPTIONALITY_EXEMPTIONS (tests/spec_coverage_test.rs:298)

No PgConfig, PostgresInstanceConfig, or PgBouncerConfig entries. Only ServicePostRequest and ApiKeyPostRequest are listed.

Recommended next action: escalate upstream + add local exemption

The right fix is upstream in the spec, but we can also unblock the test locally now via OPTIONALITY_EXEMPTIONS. I recommend doing both.

1. Local unblock (do now, in this issue)

Add to OPTIONALITY_EXEMPTIONS in tests/spec_coverage_test.rs, then re-run scripts/update-models-optionality.py (or hand-edit models.rs) to convert these to Option<T> and add #[serde(skip_serializing_if = "Option::is_none")]:

// The `pgConfig` schema has no `required` array and no field descriptions
// start with "Optional", so our resolver marks every field required.
// However the endpoint is a partial-update style API: sending the default
// value for any field yields
// `Validation failed for following fields: pg_config.*`. Every property is
// effectively optional. Exempt them all until the spec adds proper required
// semantics (upstream issue: <link>).
("PgConfig", "default_transaction_isolation"),
("PgConfig", "effective_cache_size"),
("PgConfig", "effective_io_concurrency"),
("PgConfig", "idle_in_transaction_session_timeout"),
("PgConfig", "idle_session_timeout"),
("PgConfig", "lock_timeout"),
("PgConfig", "maintenance_work_mem"),
("PgConfig", "max_connections"),
("PgConfig", "max_parallel_maintenance_workers"),
("PgConfig", "max_parallel_workers"),
("PgConfig", "max_parallel_workers_per_gather"),
("PgConfig", "max_slot_wal_keep_size"),
("PgConfig", "max_wal_size"),
("PgConfig", "max_worker_processes"),
("PgConfig", "min_wal_size"),
("PgConfig", "random_page_cost"),
("PgConfig", "statement_timeout"),
("PgConfig", "transaction_timeout"),
("PgConfig", "wal_compression"),
("PgConfig", "wal_keep_size"),
("PgConfig", "wal_sender_timeout"),
("PgConfig", "work_mem"),
// `postgresInstanceConfig` lists both nested objects as required, but PATCH
// is partial-update so callers must be able to send only one of them.
("PostgresInstanceConfig", "pgConfig"),
("PostgresInstanceConfig", "pgBouncerConfig"),

PgBouncerConfig itself is fine once it's Option<…> at the wrapper level — the empty-struct shape becomes a non-issue because callers just omit the whole field.

2. Upstream spec fix (file separately against the cloud OpenAPI spec)

Draft text:

Title: pgConfig / postgresInstanceConfig schemas declare every field required, but the runtime-config POST/PATCH endpoints reject default values

Endpoints: postgresInstanceConfigPost, postgresInstanceConfigPatch
Schemas: components.schemas.pgConfig, components.schemas.postgresInstanceConfig

Problem: Both endpoints are partial-update style — callers expect to send only the parameters they want to change. However:

1. pgConfig has no required array, no field descriptions start with the word "Optional", and the schema sets additionalProperties: false + minProperties: 1. Code generators that interpret a missing required array as "all fields required" produce structs that serialise default values for every property, and the API responds with Validation failed for following fields: pg_config.*.
2. postgresInstanceConfig (used as the request body for both POST and PATCH) declares required: ["pgConfig", "pgBouncerConfig"]. For PATCH this prevents callers from updating only one of the two nested objects.

Proposed fix:

• On pgConfig: either remove the schema-level "all fields required" implication (add "required": [] explicitly, or prepend each property description with the word "Optional"), or — preferred — split the schema into a separate pgConfigPatchRequest that mirrors current PATCH semantics, with no required array and all properties optional.
• On postgresInstanceConfig: drop pgBouncerConfig and pgConfig from the required array on the PATCH path (a separate …PatchRequest schema is the cleanest model — this is the project's existing convention for PATCH bodies).
• On individual pgConfig properties whose type is ["string","integer"]: explicitly add null to the type union, e.g. "type": ["string","integer","null"], since the existing Rust generator already routes nullable polymorphic params through Option<serde_json::Value> to avoid the null body-validation problem.

Once that ships, update-models-optionality.py will flip these fields to Option<T>, the exemptions become stale (detected automatically by field_optionality_matches_spec), we remove them, and #163 can take the full POST/PATCH round-trip without further model changes.