OpenAIHostedFileClient: the removed openai-dotnet#733 workaround defended two fields, upstream fixed one

[tufantunc]

Description

#7608 removed the openai-dotnet#733 workaround along with the OpenAI 2.11.0 to 2.12.0 bump. That workaround defended two fields against explicit JSON nulls: bytes and created_at.

The upstream fix covers bytes only. created_at is still deserialized with a bare GetInt64(), which throws InvalidOperationException on a JSON null. Filed upstream as openai/openai-dotnet#1318 with the exact lines.

On main at acb85d7 there is no remaining reference to 733 in OpenAIHostedFileClient.cs, so this library now relies entirely on the SDK guarding both fields.

Filing here mainly so there is something to link the upstream fix to. If you would rather track it only upstream, closing this is fine.

A separate, smaller correction

#7608 frames the version bump as the enabler for dropping the workaround. The null-bytes guard was already present in 2.11.0, the version the repo was on. I checked the SDK source at both tags.

The bump is genuinely needed, but for a different reason: ListFilesAsync was reshaped to 2.12.0's ContainerFileCollectionOptions(string containerId) constructor.

Worth noting only because the stated rationale is what a future reader will trust when deciding whether the removal was safe. Nothing to fix in code.

Reproduction Steps

None. I found this by reading the SDK deserializer and diffing it against the two tags, not from a crash.

Whether it is reachable in practice depends on whether the OpenAI API ever emits "created_at": null for container files, which I could not confirm. That question is open on the upstream issue.

Expected behavior

Deserializing a container file whose created_at is an explicit JSON null yields an object, or a typed error.

Actual behavior

InvalidOperationException from JsonElement.GetInt64(), the same exception class the removed workaround existed to prevent.

Regression?

Yes, in the sense that the workaround previously covered this field and no longer does. Not a regression in observed behaviour, since I have no confirmed occurrence.

---

_{Found while evaluating an AI code-review tool I maintain against merged agent-authored PRs. Hand-verified against upstream source before filing.}

[tufantunc]

Closing this myself: the premise does not hold.

I filed it on the basis that dropping the openai-dotnet#733 workaround left this library exposed on created_at, since the upstream fix guarded only bytes. A maintainer has now answered that question upstream in openai/openai-dotnet#1318: created_at is a required property in the OpenAI REST API specification, so the service guarantees it is never null, and the asymmetry with bytes is intentional rather than an oversight. bytes is nullable in the spec; created_at is not. Throwing on a payload that violates a required-property contract is the intended behaviour, not a gap.

So there is nothing here for this library to defend against, and the workaround removal in #7608 was safe.

The second, smaller point stands but needs no action: the null-bytes guard was already present in 2.11.0, so the bump was necessary for the ContainerFileCollectionOptions(string containerId) reshape rather than for the workaround removal. That is a note about a merged PR's description, with nothing to change in code, and it is not worth an open issue on its own.

Apologies for the noise, and thanks for leaving it untriaged rather than spending time on it.