Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Allow sending request fields absent from Discovery (Developer Preview surfaces) — e.g. `--no-validate`

Đang mở
  • Có gì không ổn?
#901 0 bình luận 2 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
api, cli

Hướng nghiên cứu

Start at the CLI's request-body validation path and the existing --dry-run option. Trace how request bodies are forwarded after validation, then verify that an explicit opt-out sends unknown fields while default validation remains unchanged. Done means the new option works for the documented preview requests and its behavior is covered by tests or CLI documentation.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

gws validates request bodies against the service's public Discovery document. For Google Workspace APIs that have Developer Preview surfaces, that makes gws strictly less capable than the API it wraps: Google documents those request types in the REST reference and the live API accepts them, but they are absent from public Discovery, so gws rejects them locally before anything is sent.

There is currently no way to opt out.

Concrete example — Docs API comments and suggestions

The Docs API's comment/suggestion surface (Developer Preview) includes insertComment, addCommentReply, updateCommentPost, deleteComment, deleteCommentReply, acceptSuggestion, rejectSuggestion, deleteSuggestion, plus writeControl.writeMode = "SUGGEST".

gws refuses all of them. Both of these are real output from gws 0.22.5, with the long "valid properties" list elided:

$ gws docs documents batchUpdate --params '{"documentId":"…"}' \
    --json '{"requests":[{"addCommentReply":{"commentId":"…","post":{"content":"x"}}}]}' --dry-run
error[validation]: Request body failed schema validation:
- requests[0].addCommentReply: Unknown property. Valid properties: ["deleteTableRow", "addDocumentTab", … 40 total …, "deleteFooter"]

$ gws docs documents batchUpdate --params '{"documentId":"…"}' \
    --json '{"requests":[{"insertText":{"location":{"index":1},"text":"x"}}],"writeControl":{"writeMode":"SUGGEST"}}' --dry-run
error[validation]: Request body failed schema validation:
- writeControl.writeMode: Unknown property. Valid properties: ["requiredRevisionId", "targetRevisionId"]

The same requests succeed against docs.googleapis.com over plain HTTPS with the documents scope, on a Cloud project enrolled in the Workspace Developer Preview Program. Verified end to end: addCommentReply posted a reply that is visible in the Docs UI, and writeMode: "SUGGEST" + insertText created a real suggestion which was then read back with suggestionsViewMode=SUGGESTIONS_INLINE and removed with rejectSuggestion.

Why this can't be fixed by configuration

Public Discovery for Docs v1 omits the entire preview surface, via both endpoints, checked today:

Endpoint revision Request properties WriteControl properties
https://www.googleapis.com/discovery/v1/apis/docs/v1/rest 20260812 40 requiredRevisionId, targetRevisionId
https://docs.googleapis.com/$discovery/rest?version=v1 20260812 40 requiredRevisionId, targetRevisionId

None of the 40 Request properties are the preview ones. The labels= query parameter that exposes preview schemas on some Google APIs is accepted but ignored here — labels=DEVELOPER_PREVIEW, labels=PREVIEW and labels=LIMITED_AVAILABILITY all return byte-identical documents (236,739 bytes).

So there is no preview Discovery document to point gws at, and the validation cannot be satisfied by supplying a different schema URL or API version. (--api-version selects v1/v2/v3, not a release channel.)

Request

Any one of these would resolve it:

  1. --no-validate (or --skip-validation) — send the body as given and let the API be the authority. Smallest change, keeps validation as the default.
  2. --discovery-file <PATH> — override the Discovery document for a call, so a hand-augmented schema can be supplied.
  3. Warn instead of erroring on unknown properties, perhaps behind a flag, so unknown fields are forwarded rather than rejected.

(1) looks like the best fit for a CLI whose surface is generated from the API's own description, and it pairs naturally with the existing --dry-run (Validate the request locally without sending it to the API) as its inverse.

Related but distinct: #670 is about reaching services absent from the hardcoded list. This is about fields absent from a listed service's schema — the same "Discovery is the gate" root, but a different gate.

Workaround

A ~370-line Python helper that reads the same authorized_user credentials file gws uses, mints an access token, and POSTs to docs.googleapis.com directly. It works, but it duplicates auth handling and exists only to route around client-side validation — exactly the kind of thing one would rather not maintain alongside gws. It gets deleted the moment either this surface reaches GA or a flag like the above lands.

Environment
  • gws 0.22.5 (current latest release)
  • Docs API v1, Discovery revision 20260812
  • Cloud project enrolled in the Google Workspace Developer Preview Program
Ngôn ngữ chính
Rust
Star
31.3k
Fork
1.9k
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của googleworkspace/cli

Tất cả issue của googleworkspace/cli

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.