feat: API specs update for version 1.9.x#79
Conversation
Greptile SummaryThis bot-generated PR updates the 1.9.x API specs with two main changes: new OAuth2 consent fields (
Confidence Score: 3/5The OpenAPI3 changes look correct, but the unexplained deletion of all three swagger2 files breaks a pattern every other version in the repo follows and would immediately impact any consumer relying on swagger2 for 1.9.x. The new App fields and database model changes in the OpenAPI3 specs are consistent and well-formed. The concern is the complete, unexplained removal of the swagger2 spec files — every version from 0.6.x through 1.8.x ships both OpenAPI3 and swagger2; 1.9.x would be the sole exception. If this is an unintentional bot regression rather than a deliberate deprecation, those files would need to be regenerated before merge. The three deleted swagger2 files (swagger2-1.9.x-client.json, swagger2-1.9.x-console.json, swagger2-1.9.x-server.json) need explicit confirmation that their removal is intentional before merging. Important Files Changed
Reviews (2): Last reviewed commit: "(chore): remove swagger 2 specs for 1.9...." | Re-trigger Greptile |
| "x-example": null, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "supportUrl": { | ||
| "type": "string", | ||
| "description": "Application support URL shown to users during OAuth2 consent.", | ||
| "default": "", |
There was a problem hiding this comment.
images items missing URL format annotation
supportUrl and dataDeletionUrl both carry "format": "url" to signal that values must be URLs, but the string items inside the images array do not. Since the field is described as "image URLs," the items should declare the same format for consistency with the rest of the schema and to give SDK generators and validators an accurate type hint. The same gap exists in the images field in open-api3-1.9.x-client.json and open-api3-1.9.x-server.json.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| }, | ||
| "tags": { | ||
| "type": "array", | ||
| "description": "Application tags shown to users during OAuth2 consent. Maximum of 100 tags are allowed, each up to 64 characters long.", | ||
| "default": [], | ||
| "x-example": null, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "images": { | ||
| "type": "array", | ||
| "description": "Application image URLs shown to users during OAuth2 consent. Maximum of 100 images are allowed.", | ||
| "default": [], | ||
| "x-example": null, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "supportUrl": { | ||
| "type": "string", | ||
| "description": "Application support URL shown to users during OAuth2 consent.", | ||
| "default": "", |
There was a problem hiding this comment.
x-example: null on tags and images request-body fields
The tags and images array fields in the create/update request bodies use "x-example": null, while the App model schema (the response definition) provides concrete example values (["productivity","automation"] and ["https://example.com/screenshot.png"] respectively). Many SDK generators and documentation renderers surface x-example directly; null suppresses the example entirely in generated docs and client stubs even though meaningful values are available. Using the same concrete examples as the model schema would keep generated SDKs and documentation consistent. The same pattern appears in both the client and server specs.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Specs are generated and consumed as OpenAPI 3 only since appwrite/sdk-generator 2.0.0 and appwrite/appwrite#12565.
This PR contains API specification updates for version 1.9.x, regenerated through the OpenAPI 3 only pipeline (appwrite/sdk-generator 2.0.0 + appwrite/appwrite#12565).
It also removes the
swagger2-1.9.x-*spec files: specs are generated and consumed as OpenAPI 3 only now. Swagger 2 files for older versions (1.8.x and below) are kept as historical artifacts.