We had this annotation everywhere in app-server APIs which made it so that fields get serialized as `field?: T`, meaning if the field as `None` we would omit the field in the payload. Removing this annotation changes it so that we return `field: T | null` instead, which makes codex app-server's API more aligned with the convention of public OpenAI APIs like Responses. Separately, remove the `#[ts(optional_fields = nullable)]` annotations that were recently added which made all the TS types become `field?: T | null` which is not great since clients need to handle undefined and null. I think generally it'll be best to have optional types be either: - `field: T | null` (preferred, aligned with public OpenAI APIs) - `field?: T` where we have to, such as types generated from the MCP schema: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-06-18/schema.ts (see changes to `mcp-types/`) I updated @etraut-openai's unit test to check that all generated TS types are one or the other, not both (so will error if we have a type that has `field?: T | null`). I don't think there's currently a good use case for that - but we can always revisit.
29 lines
724 B
Rust
29 lines
724 B
Rust
use schemars::JsonSchema;
|
|
use serde::Deserialize;
|
|
use serde::Serialize;
|
|
use ts_rs::TS;
|
|
|
|
// Types for the TODO tool arguments matching codex-vscode/todo-mcp/src/main.rs
|
|
#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema, TS)]
|
|
#[serde(rename_all = "snake_case")]
|
|
pub enum StepStatus {
|
|
Pending,
|
|
InProgress,
|
|
Completed,
|
|
}
|
|
|
|
#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema, TS)]
|
|
#[serde(deny_unknown_fields)]
|
|
pub struct PlanItemArg {
|
|
pub step: String,
|
|
pub status: StepStatus,
|
|
}
|
|
|
|
#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema, TS)]
|
|
#[serde(deny_unknown_fields)]
|
|
pub struct UpdatePlanArgs {
|
|
#[serde(default)]
|
|
pub explanation: Option<String>,
|
|
pub plan: Vec<PlanItemArg>,
|
|
}
|