fix(slides): build create URL locally instead of drive metas call#1329
Merged
Conversation
github-actions
Bot
added
the
size/M
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughSlidesCreate now constructs presentation URLs locally (via common.BuildResourceURL) and documents that no drive scope is required; tests were updated to expect locally built URLs and removed drive metas/batch_query stubbing. ChangesSlides URL Resolution
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@7156a2b87bf0be3dba1730f371e8959d98bb94b5🧩 Skill updatenpx skills add larksuite/cli#fix/slides-create-drive-meta-scope -y -g |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@shortcuts/slides/slides_create.go`:
- Around line 211-219: Update the tests to match the new local URL construction
behavior: remove or stop using registerBatchQueryStub calls in
slides_create_test.go (tests should no longer assume
/open-apis/drive/v1/metas/batch_query is called), update TestSlidesCreateBasic's
expected presentation URL to use the brand host returned by
common.BuildResourceURL (e.g. change expected https://example.feishu.cn/... to
https://www.feishu.cn/...), and modify TestSlidesCreateURLFetchBestEffort to
assert that result["url"] is present (since common.BuildResourceURL now always
sets the url) instead of expecting no url.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4b6324c9-e27f-47d3-b4c1-821e41079b2f
📒 Files selected for processing (1)
shortcuts/slides/slides_create.go
fangshuyu-768
previously approved these changes
Jun 8, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1329 +/- ##
==========================================
- Coverage 71.47% 71.47% -0.01%
==========================================
Files 688 688
Lines 65482 65467 -15
==========================================
- Hits 46806 46791 -15
Misses 15031 15031
Partials 3645 3645 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
slides +create finished by calling /drive/v1/metas/batch_query just to fetch the presentation URL. That call needs a drive scope the shortcut never declares, so it 403'd for users who only authorized slides scopes (both UserAccessToken re-auth and TenantAccessToken scope-not-opened), producing a large share of the shortcut's failure telemetry — even though the presentation itself was already created successfully. slides creation never otherwise touches drive, so rather than gating a drive-free operation behind a drive scope, build the URL locally from the token via common.BuildResourceURL (the same brand-standard-host fallback already used by drive +upload / wiki +node-create). The URL is now always returned, no extra scope is required, and creation never blocks. Tests are updated to match: drop the registerBatchQueryStub helper and its call sites (the httpmock Verify cleanup was failing on the now-unconsumed batch_query stubs), point url assertions at the brand-standard host, and replace TestSlidesCreateURLFetchBestEffort with TestSlidesCreateURLBuiltLocally, which asserts the url is produced with no drive call registered.
ViperCai
force-pushed
the
fix/slides-create-drive-meta-scope
branch
from
050643a to
7156a2b
Compare
fangshuyu-768
approved these changes
Jun 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
While analyzing
slides:+createfailure telemetry (2026-06-07), the single largest fixable cluster was the post-creation URL lookup, not the creation itself.slides +createended its flow with a call to/open-apis/drive/v1/metas/batch_querypurely to fetch the presentation URL (slides_create.go, Execute). That call needs a drive scope that the shortcut never declares, so it failed for two populations:UserAccessToken→99991679(user hasn't authorizeddrive:drive/drive:drive.metadata:readonly)TenantAccessToken→99991672(app hasn't opened the drive scope)Together these accounted for ~64 failure events (~34% of the shortcut's failures) in the sample — even though in almost all cases the presentation was already created successfully and only this best-effort enrichment call failed. It inflated failure counts and dropped the
urlfrom the result.Why not just declare the drive scope?
markdown +create/drive +uploaddo declaredrive:drive.metadata:readonly— but their core operation is a drive upload (drive:file:uploadis mandatory anyway), so the read scope is a free add-on.slidescreation goes throughslides_aiand never otherwise touches drive, so requiring a drive scope would gate an otherwise drive-free operation and block creation at preflight for users who only authorized slides scopes. That's a worse trade than the bug.Fix
Drop the drive call entirely and build the URL locally from the token via
common.BuildResourceURL(runtime.Config.Brand, "slides", presentationID)— the same brand-standard-host fallback already used bydrive +upload,wiki +node-create, andsheets. The host transparently redirects to the tenant domain.Result:
urlis always returned.Scope / out of scope
TenantAccessTokenslides:presentation:createfailures stem from silent bot-identity fallback (problem A) and are not in this PR.Diff
shortcuts/slides/slides_create.go: +11 / −23 (remove inlinemetas/batch_queryblock →BuildResourceURL; comment note on why no drive scope).Testing
lark-cli slides +createreturns a workingurlwithout any drive scope granted./drive/v1/metas/batch_querycall is made (verify via--dry-run/ network trace).Summary by CodeRabbit
Bug Fixes
Refactor
Tests