fix(api): serialize snowflake ids as strings for JS precision - #2179
Conversation
Connect via websocketProvider attach/connect (provider.connect is a no-op), derive SYNC_URL from WEB_URL for rust/rk8s/dev, and allow local HMR origins.
Snowflake i64s exceed Number.MAX_SAFE_INTEGER and truncated in the browser (e.g. Admin Group delete 404). Serde/OpenAPI/path params and web clients now keep ids as strings; merge-swagger rewrites path refs for gen-client. Skip mono notes lookup until that table is migrated.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8ce36fe218
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| build_id: build.id, | ||
| cl_link: cl, | ||
| cl_id: clId ?? 0, | ||
| cl_id: clId ?? '', |
There was a problem hiding this comment.
Keep retry payload compatible with Orion
When a user retries a build from the Checks view, this now sends cl_id as a JSON string (or "" when unavailable), but /v2/retry-build extracts Json<RetryBuildRequest> and api-model/src/buck2/api.rs still declares cl_id: i64 without a string-compatible deserializer. Serde therefore rejects the request before build_retry runs, so the retry action fails; update the shared Orion request model to accept string snowflakes (and use a valid fallback) rather than changing only the generated TypeScript schema.
Useful? React with 👍 / 👎.
| path = "/{id}", | ||
| params( | ||
| ("id" = i64, Path, description = "Trigger ID") | ||
| ("id" = SnowflakeId, Path, description = "Trigger ID") |
There was a problem hiding this comment.
Serialize trigger IDs before exposing string paths
For clients that obtain a trigger from the create/list endpoints and then call this get or retry route, TriggerResponse.id is still serialized as a bare i64 (ceres/src/application/build_trigger/model.rs), while this change makes the route parameter and generated client argument a string. Current trigger IDs exceed JavaScript's safe-integer range, so the response ID is already corrupted before it can be placed in the path; apply the snowflake string serializer/schema to TriggerResponse.id (and its snowflake reference fields) as well.
Useful? React with 👍 / 👎.
No description provided.