test(im): drop --yes from chats link e2e (not high-risk-write) - #700
Conversation
`im chats link` is registered as a regular service method (no `risk: high-risk-write` annotation), so the framework does not register the `--yes` flag on it. Setting `Yes: true` on the e2e Request makes the runner append `--yes`, which cobra rejects with `unknown flag: --yes` before the request is ever issued — the rest of the assertions then fall through with empty stdout. The flag was added in #633 alongside the risk-tiering rollout that covered other workflows that genuinely flipped to high-risk-write. For chats link the API call (creating a chat share link with a configurable validity period) is not destructive and was never re-classified, so the line is just leftover from that pass. Drop it to restore the e2e green; if we ever decide to gate share-link creation behind confirmation we can re-add it together with the metadata flip. Change-Id: Ieb094407a7f0fa18cd130a9d80c7146274b5ecc7
|
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 (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe e2e test for Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #700 +/- ##
=======================================
Coverage 63.80% 63.80%
=======================================
Files 500 500
Lines 43531 43531
=======================================
Hits 27773 27773
Misses 13317 13317
Partials 2441 2441 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@d7ac927386cd8a63b324ecbec1d8a8bb6d504ae3🧩 Skill updatenpx skills add larksuite/cli#fix/im-chats-link-yes-flag -y -g |
…uite#700) `im chats link` is registered as a regular service method (no `risk: high-risk-write` annotation), so the framework does not register the `--yes` flag on it. Setting `Yes: true` on the e2e Request makes the runner append `--yes`, which cobra rejects with `unknown flag: --yes` before the request is ever issued — the rest of the assertions then fall through with empty stdout. The flag was added in larksuite#633 alongside the risk-tiering rollout that covered other workflows that genuinely flipped to high-risk-write. For chats link the API call (creating a chat share link with a configurable validity period) is not destructive and was never re-classified, so the line is just leftover from that pass. Drop it to restore the e2e green; if we ever decide to gate share-link creation behind confirmation we can re-add it together with the metadata flip. Change-Id: Ieb094407a7f0fa18cd130a9d80c7146274b5ecc7
…uite#700) `im chats link` is registered as a regular service method (no `risk: high-risk-write` annotation), so the framework does not register the `--yes` flag on it. Setting `Yes: true` on the e2e Request makes the runner append `--yes`, which cobra rejects with `unknown flag: --yes` before the request is ever issued — the rest of the assertions then fall through with empty stdout. The flag was added in larksuite#633 alongside the risk-tiering rollout that covered other workflows that genuinely flipped to high-risk-write. For chats link the API call (creating a chat share link with a configurable validity period) is not destructive and was never re-classified, so the line is just leftover from that pass. Drop it to restore the e2e green; if we ever decide to gate share-link creation behind confirmation we can re-add it together with the metadata flip. Change-Id: Ieb094407a7f0fa18cd130a9d80c7146274b5ecc7
Summary
Fixes the failing
TestIM_ChatsLinkWorkflow/get_chat_share_link_as_botonmain(and on every open PR) by removing a strayYes: truefrom the e2e Request.Root cause
im chats linkis a generic service method whose metadata does not carryrisk: "high-risk-write", socmd/service/service.gonever registers the--yesflag on it. Once #633 landed and addedYes: trueto this test, the e2e runner started appending--yesto every invocation; cobra rejects it before the request is dispatched:That tanks
AssertExitCode(t, 0), thenAssertStdoutStatus, then theshare_link should not be emptycheck. CI run onmainconfirming the regression: https://github.com/larksuite/cli/actions/runs/25056050086Why drop the flag instead of marking the API as high-risk-write
Generating a chat share link with a configurable validity period is non-destructive — it doesn't delete data, doesn't alter membership, and the link can be invalidated. The other tests touched in #633 (calendar event delete, sheets filter remove, task delete, etc.) genuinely flipped to high-risk-write at the metadata layer;
im.chats.linkdid not. So theYes: truehere is leftover from the bulk pass, not a missing metadata flip.If product later decides share-link creation should require confirmation, the right move is to flip the metadata risk and re-add
Yes: truetogether — not to keep a flag that the binary doesn't accept.Test plan
go build ./...go vet ./tests/cli_e2e/im/...Summary by CodeRabbit
Release Notes
No user-facing changes in this release. This update includes internal test infrastructure modifications only.