* fix(sheets): repair the build after the local-office detection move
main does not compile: shortcuts/sheets/lark_sheet_workbook.go references
isOfficeSpreadsheet and officePrefixes, which no longer exist in the package.
Neither PR was wrong on its own. #2531 (merged 10:39) moved local-office token
detection into common.IsLocalOfficeToken and deleted the sheets-local copies;
#2533 (merged 12:48) added errLocalOfficeExportUnsupported, which calls them.
#2533's branch predated the move, so its CI was green against a base that still
had the symbols, and merging it left main broken.
Repoints both references at the moved API. Behaviour is unchanged:
common.IsLocalOfficeToken is the same predicate #2531 moved, and the prefix pair
is the exported form of the same two constants. #2533's own coverage —
TestWorkbookExport_LocalOfficeTokenRejected across the local_office_ prefix, the
fake_office_ prefix, and an interleaved OFL0X token, plus the wiki-node and
dry-run cases — passes unchanged, which is what pins the equivalence.
* fix(sheets): derive dry-run image parent_type from the ref kind, not the token
A `/wiki/` URL reaches a DryRun hook as the wiki node_token: resolving it to the
backing spreadsheet needs the get_node call a preview must not make. Both
image-upload previews fed that node_token straight to sheetMediaParentType, so
the parent_type they showed was derived from a token that is not the one Execute
uploads against. A node_token shaped like an imported office token previewed
office_sheet_file for a spreadsheet that will upload as sheet_image.
sheetsDryRunParentType decides from the ref's kind instead. A wiki ref is native
by construction, not by default: resolveWikiNodeToSpreadsheetToken rejects any
node whose obj_type is not "sheet", and a spreadsheet backed by an imported
office file sits in drive as a "file" node, so it never survives that gate to
reach an upload. Execute is unaffected either way — it derives from the resolved
token. This mirrors slidesDryRunParentType, which the slides domain already
applies for the same reason.
The hooks now hold the parsed ref rather than re-deriving the token from it, so
the kind is visible where the preview is built.
Also records, at uploadSheetMediaFile, that office_sheet_file survives the
multipart path. Slides caps image uploads at 20 MB because upload_prepare
rejects its parent types outright, which raised the question for sheets, whose
deprecated +media-upload has no such cap. Verified against the live API:
upload_prepare accepts both sheet_image and office_sheet_file, and a 20.6 MB
file uploaded with office_sheet_file completes prepare -> 6 x upload_part ->
upload_finish and returns a file_token a float image then accepts.
Tests: sheetsDryRunParentType over both ref kinds, including wiki refs carrying
office-shaped and office-prefixed node tokens; dry-run coverage through the
public flags for +cells-set-image and +float-image-create, each checked against
the identical token as a /wiki/ URL and as a raw spreadsheet token so the two
rows differ only in kind; the same pair added to the e2e dry-run lane. All four
fail against the previous behaviour.
* fix(sheets): send oversized images through the chunked upload, not upload_all
uploadSheetImage always used the single-part endpoint, so an image past the
20 MB ceiling failed with a bare 1061002 "upload media failed: params error"
naming neither the size nor the limit. The capability was already in the domain:
the deprecated sheets +media-upload has dispatched by size since it was written
(backward.uploadSheetMediaFile), which left the same image succeeding through
the old shortcut and failing through +cells-set-image and +float-image-create,
the ones meant to replace it.
uploadSheetImage now picks the endpoint by size the way doc and the deprecated
shortcut already do. The parent_type is unchanged and still comes from
sheetMediaParentType, so the office/native split rides along either branch.
The preview follows the same branch. appendSheetImageUploadDryRun renders one
upload_all under the ceiling and the upload_prepare / upload_part /
upload_finish trio above it, and both image-write hooks now build their upload
step through it rather than each spelling out an upload_all. A preview that
promised a single-part upload for a file the CLI will send in chunks is a
preview of a different request.
Verified against the live API with a 20.6 MB PNG: +cells-set-image and
+float-image-create both complete, the cell reads back holding the uploaded
image_token at the file's real 3000x2400 dimensions, and the dry-run shows the
three chunked steps Execute hits. The same file failed with 1061002 before.
Tests: the chunked branch at exactly one byte past the ceiling, asserted through
upload_prepare's parent_type with upload_all deliberately left unstubbed so a
regression fails loudly; the preview's step list on both sides of the boundary,
as a unit test and in the e2e dry-run lane. All fail against the previous
behaviour.
xiongyuanwen-byted