feat(wiki): add +delete-space shortcut with async task polling#610
feat(wiki): add +delete-space shortcut with async task polling#610fangshuyu-768 merged 1 commit intomainfrom
Conversation
github-actions
Bot
added
domain/ccm
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdded a new wiki deletion shortcut Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as "lark-cli (wiki +delete-space / drive +task_result)"
participant WikiAPI as "Wiki API\n(open-apis/wiki/v2)"
participant TaskAPI as "Tasks API\n(open-apis/wiki/v2/tasks)"
CLI->>WikiAPI: DELETE /spaces/:space_id (--yes)
alt synchronous (data.task_id empty)
WikiAPI-->>CLI: 200 {data.task_id: ""}
CLI-->>User: return ready=true, failed=false, space_id
else asynchronous (data.task_id present)
WikiAPI-->>CLI: 202 {data.task_id: T}
loop poll (up to 30 × 2s)
CLI->>TaskAPI: GET /tasks/T?task_type=delete_space
TaskAPI-->>CLI: {data.task.delete_space_result.status, status_msg, task_id?}
end
alt status == success
CLI-->>User: ready=true, failed=false, status="success", task_id
else status == failure/failed
CLI-->>User: error (failed=true, status_msg)
else timeout
CLI-->>User: ready=false, timed_out=true, next_command="drive +task_result --scenario wiki_delete_space --task-id T"
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #610 +/- ##
==========================================
- Coverage 61.69% 60.09% -1.61%
==========================================
Files 402 406 +4
Lines 35073 42924 +7851
==========================================
+ Hits 21639 25794 +4155
- Misses 11429 15111 +3682
- Partials 2005 2019 +14 ☔ 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@4a8c97b8594f4ebd21e6031dc205c3a6dc695b70🧩 Skill updatenpx skills add larksuite/cli#feat/wiki-space-delete -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: 3
🧹 Nitpick comments (3)
shortcuts/wiki/wiki_delete.go (1)
82-103: NormalizeStatusconsistently acrossReady()/Failed()/StatusLabel().
Ready()usesstrings.EqualFold(s.Status, "success")(case-insensitive, no trim) whileFailed()usesstrings.ToLower(strings.TrimSpace(s.Status)) == "failure" || "failed"(case-insensitive, trims whitespace). A backend reply of" SUCCESS "would be classified as neither ready nor failed, so polling keeps looping and the command times out withtimed_out=truedespite a terminal success. Pick one normalization (preferToLower(TrimSpace(...))) and use it in all three methods.♻️ Proposed fix
func (s wikiDeleteSpaceTaskStatus) Ready() bool { - return strings.EqualFold(s.Status, wikiDeleteSpaceStatusSuccess) + return strings.ToLower(strings.TrimSpace(s.Status)) == wikiDeleteSpaceStatusSuccess }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete.go` around lines 82 - 103, Normalize s.Status using strings.ToLower(strings.TrimSpace(s.Status)) consistently across wikiDeleteSpaceTaskStatus methods: in Ready() replace strings.EqualFold(s.Status, wikiDeleteSpaceStatusSuccess) with a check against the normalized status == wikiDeleteSpaceStatusSuccess; in Failed() keep the existing normalization but compare against wikiDeleteSpaceStatusFailure and "failed" using the normalized variable; in StatusLabel() trim StatusMsg as now but when falling back to Status use the normalized status (or return wikiDeleteSpaceStatusProcessing if empty) so `" SUCCESS "` is treated as success by Ready() and StatusLabel().shortcuts/drive/drive_task_result.go (1)
480-534: Consider sharing normalization withwiki_delete.goto prevent drift.This function duplicates the
delete_space_resultparsing andready/failed/status_msgderivation thatshortcuts/wiki/wiki_delete.goalready encapsulates viaparseWikiDeleteSpaceTaskStatus+wikiDeleteSpaceTaskStatus(Ready()/Failed()/StatusLabel()). There is also a subtle normalization divergence: herereadyis computed asstrings.ToLower(strings.TrimSpace(status)) == "success", whilewikiDeleteSpaceTaskStatus.Ready()usesstrings.EqualFold(s.Status, "success")without trimming — the two call sites will disagree if the backend ever returns" success ".Exporting the helpers from the
wikipackage (or moving them to a sharedcommonhelper) and reusing them here would keepwiki +delete-spaceanddrive +task_result --scenario wiki_delete_spacein lockstep.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/drive/drive_task_result.go` around lines 480 - 534, queryWikiDeleteSpaceTask duplicates delete_space_result parsing and status normalization already implemented in parseWikiDeleteSpaceTaskStatus and wikiDeleteSpaceTaskStatus (Ready/Failed/StatusLabel) causing drift (trim vs EqualFold). Fix by reusing the existing helpers: import or export parseWikiDeleteSpaceTaskStatus/wikiDeleteSpaceTaskStatus from the wiki package (or move them to a shared helper) and replace the inline parsing/ready/failed/status_msg logic in queryWikiDeleteSpaceTask with calls to those helpers so both callers share identical normalization semantics.shortcuts/wiki/wiki_delete_test.go (1)
241-269: Test name advertises "Repeated" poll failures but only exercises a single attempt.
withSingleWikiDeleteSpacePollpinswikiDeleteSpacePollAttempts = 1, so this test only validates hint-wrapping on the first/only failure, and the stderr assertion on line 266 ("attempt 1/1 failed") is locked to that single-attempt configuration. Any logic that accumulates or dedupes across multiple failed polls (e.g., using only the last hint, suppressing intermediate ones) is not exercised. Consider either renaming to reflect single-attempt behavior, or adding a second case that configures >1 attempts with multipletaskErrsentries to cover the genuinely "repeated" path.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete_test.go` around lines 241 - 269, The test TestPollWikiDeleteSpaceTaskWrapsRepeatedPollFailuresWithHint claims to exercise repeated poll failures but uses withSingleWikiDeleteSpacePoll which pins wikiDeleteSpacePollAttempts = 1; either rename the test to reflect a single-attempt case or add a new test that sets wikiDeleteSpacePollAttempts > 1 (use a helper like with... to configure attempts or set the package var directly), create a fakeWikiDeleteSpaceClient with multiple taskErrs entries (one per attempt), call pollWikiDeleteSpaceTask with that client/runtime/task ID, and update assertions to expect multi-attempt stderr messages (e.g., "attempt 1/3" and "attempt 3/3") and that the wrapped ExitError hint contains the expected original hint plus the resume command from wikiDeleteSpaceTaskResultCommand("task_123", core.AsUser).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@shortcuts/drive/drive_task_result_test.go`:
- Around line 486-520: The test TestDriveTaskResultWikiDeleteSpaceRunning is
misnamed because it asserts a terminal success (delete_space_result.status ==
"success"); rename the test function to
TestDriveTaskResultWikiDeleteSpaceSuccess and update any references/imports or
test runners accordingly (e.g., function name used in mountAndRunDrive calls or
test listings), or alternatively add a new test
TestDriveTaskResultWikiDeleteSpaceRunning that stubs "processing" status to
exercise the running state while keeping this test to verify the
success/ready/failed assertions.
In `@shortcuts/wiki/wiki_delete.go`:
- Around line 199-211: The code sets out["status"] to the raw server value
status.Status which can be empty when delete_space_result is omitted; change the
assignment so out["status"] uses status.Status if non-empty, otherwise fall back
to status.StatusLabel() (the same fallback used by out["status_msg"]) to match
the documented `"processing"` behavior; update the block that currently sets
out["status"] (near variables out, status and the timeout branch) to perform
this conditional assignment.
In `@skills/lark-wiki/references/lark-wiki-delete-space.md`:
- Around line 75-86: The example and implementation diverge:
shortcuts/wiki/wiki_delete.go currently sets out["status"] = status.Status (raw)
which can be empty on timeout while status_msg falls back to "processing";
change the code in shortcuts/wiki/wiki_delete.go to set out["status"] =
status.StatusLabel() (or, if StatusLabel() is empty, fallback to the same
"processing" string used for status_msg) so the JSON example and actual output
match and timeouts show a human-readable "processing" status instead of an empty
string.
---
Nitpick comments:
In `@shortcuts/drive/drive_task_result.go`:
- Around line 480-534: queryWikiDeleteSpaceTask duplicates delete_space_result
parsing and status normalization already implemented in
parseWikiDeleteSpaceTaskStatus and wikiDeleteSpaceTaskStatus
(Ready/Failed/StatusLabel) causing drift (trim vs EqualFold). Fix by reusing the
existing helpers: import or export
parseWikiDeleteSpaceTaskStatus/wikiDeleteSpaceTaskStatus from the wiki package
(or move them to a shared helper) and replace the inline
parsing/ready/failed/status_msg logic in queryWikiDeleteSpaceTask with calls to
those helpers so both callers share identical normalization semantics.
In `@shortcuts/wiki/wiki_delete_test.go`:
- Around line 241-269: The test
TestPollWikiDeleteSpaceTaskWrapsRepeatedPollFailuresWithHint claims to exercise
repeated poll failures but uses withSingleWikiDeleteSpacePoll which pins
wikiDeleteSpacePollAttempts = 1; either rename the test to reflect a
single-attempt case or add a new test that sets wikiDeleteSpacePollAttempts > 1
(use a helper like with... to configure attempts or set the package var
directly), create a fakeWikiDeleteSpaceClient with multiple taskErrs entries
(one per attempt), call pollWikiDeleteSpaceTask with that client/runtime/task
ID, and update assertions to expect multi-attempt stderr messages (e.g.,
"attempt 1/3" and "attempt 3/3") and that the wrapped ExitError hint contains
the expected original hint plus the resume command from
wikiDeleteSpaceTaskResultCommand("task_123", core.AsUser).
In `@shortcuts/wiki/wiki_delete.go`:
- Around line 82-103: Normalize s.Status using
strings.ToLower(strings.TrimSpace(s.Status)) consistently across
wikiDeleteSpaceTaskStatus methods: in Ready() replace
strings.EqualFold(s.Status, wikiDeleteSpaceStatusSuccess) with a check against
the normalized status == wikiDeleteSpaceStatusSuccess; in Failed() keep the
existing normalization but compare against wikiDeleteSpaceStatusFailure and
"failed" using the normalized variable; in StatusLabel() trim StatusMsg as now
but when falling back to Status use the normalized status (or return
wikiDeleteSpaceStatusProcessing if empty) so `" SUCCESS "` is treated as success
by Ready() and StatusLabel().
🪄 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: 4b85f1c4-f807-4732-881a-ec08783f5553
📒 Files selected for processing (9)
shortcuts/drive/drive_task_result.goshortcuts/drive/drive_task_result_test.goshortcuts/wiki/shortcuts.goshortcuts/wiki/wiki_delete.goshortcuts/wiki/wiki_delete_test.goshortcuts/wiki/wiki_node_create_test.goskills/lark-drive/references/lark-drive-task-result.mdskills/lark-wiki/SKILL.mdskills/lark-wiki/references/lark-wiki-delete-space.md
liujinkun2025
force-pushed
the
feat/wiki-space-delete
branch
from
c991275 to
f0cf74c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
shortcuts/wiki/wiki_delete.go (2)
230-257: Consider short-circuiting on non-retryable API errors.The poll loop treats every
GetDeleteSpaceTaskerror as transient and retries up to 30 times at 2s intervals, so a deterministic failure (e.g., a permission error, revoked token, ortask_idnot found) forces users to wait ~60s before the resume hint is emitted. Since the initial DELETE has already succeeded, short-circuiting on clearly non-retryable errors (e.g., 4xx except 429) — or at least capping consecutive errors below the full attempt budget — would make the user-facing experience much tighter without sacrificing resilience.Additionally, note that
ctxcancellation is only observed inside thetime.Afterselect; if the CallAPI path ever gains context support, a cancelled context during the API call will not short-circuit the loop today.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete.go` around lines 230 - 257, The poll loop in the wiki delete flow treats all errors from client.GetDeleteSpaceTask as retryable, causing long unnecessary waits; update the loop in wiki_delete.go (around GetDeleteSpaceTask, wikiDeleteSpacePollAttempts, wikiDeleteSpacePollInterval) to detect non-retryable API errors (e.g., HTTP 4xx except 429) and short-circuit immediately returning the error/result instead of counting toward full retry budget (or at minimum cap consecutive errors to a smaller threshold), and after the API call check ctx.Err() so a cancelled context during the call short-circuits the loop; preserve existing behavior for transient errors (network/5xx/429) and keep lastErr/ hadSuccessfulPoll semantics for reporting.
148-153: Semantic clarity: don't usevalidateOptionalResourceNamefor required fields.The
--space-idfield is required (guarded by the empty check above), so callingvalidateOptionalResourceNameis semantically misleading. Since novalidateRequiredResourceNamevariant exists in the wiki package, either inline thevalidate.ResourceNamecall directly or create a dedicated required variant for clarity.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete.go` around lines 148 - 153, In validateWikiDeleteSpaceSpec, don't call validateOptionalResourceName for the required --space-id: replace the validateOptionalResourceName(spec.SpaceID, "--space-id") call in validateWikiDeleteSpaceSpec with a direct call to validate.ResourceName(spec.SpaceID, "--space-id") (or add and call a new validateRequiredResourceName wrapper in the wiki/validate package if you prefer a semantic helper) so the validation reflects that SpaceID is required; keep the existing empty-string guard and return the validation error directly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@shortcuts/drive/drive_task_result.go`:
- Around line 508-534: The code sets status from delete_space_result but leaves
it as an empty string while status_msg is normalized to "processing", causing
inconsistent responses; update the normalization so that after computing label
(currently from status_msg then status then "processing") you also set status =
label when status is empty/blank (use the same trimmed/lowered logic if needed)
before building the return map, ensuring status and status_msg remain in sync;
reference variables: result, status, statusMsg, label, lowered, ready, failed
and the final returned map.
---
Nitpick comments:
In `@shortcuts/wiki/wiki_delete.go`:
- Around line 230-257: The poll loop in the wiki delete flow treats all errors
from client.GetDeleteSpaceTask as retryable, causing long unnecessary waits;
update the loop in wiki_delete.go (around GetDeleteSpaceTask,
wikiDeleteSpacePollAttempts, wikiDeleteSpacePollInterval) to detect
non-retryable API errors (e.g., HTTP 4xx except 429) and short-circuit
immediately returning the error/result instead of counting toward full retry
budget (or at minimum cap consecutive errors to a smaller threshold), and after
the API call check ctx.Err() so a cancelled context during the call
short-circuits the loop; preserve existing behavior for transient errors
(network/5xx/429) and keep lastErr/ hadSuccessfulPoll semantics for reporting.
- Around line 148-153: In validateWikiDeleteSpaceSpec, don't call
validateOptionalResourceName for the required --space-id: replace the
validateOptionalResourceName(spec.SpaceID, "--space-id") call in
validateWikiDeleteSpaceSpec with a direct call to
validate.ResourceName(spec.SpaceID, "--space-id") (or add and call a new
validateRequiredResourceName wrapper in the wiki/validate package if you prefer
a semantic helper) so the validation reflects that SpaceID is required; keep the
existing empty-string guard and return the validation error directly.
🪄 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: f9e941d5-e478-4359-a5ff-caaa9cd0674d
📒 Files selected for processing (10)
shortcuts/drive/drive_task_result.goshortcuts/drive/drive_task_result_test.goshortcuts/wiki/shortcuts.goshortcuts/wiki/wiki_delete.goshortcuts/wiki/wiki_delete_test.goshortcuts/wiki/wiki_node_create_test.goskill-template/domains/wiki.mdskills/lark-drive/references/lark-drive-task-result.mdskills/lark-wiki/SKILL.mdskills/lark-wiki/references/lark-wiki-delete-space.md
✅ Files skipped from review due to trivial changes (3)
- shortcuts/wiki/shortcuts.go
- skills/lark-wiki/references/lark-wiki-delete-space.md
- shortcuts/wiki/wiki_delete_test.go
🚧 Files skipped from review as they are similar to previous changes (2)
- skills/lark-drive/references/lark-drive-task-result.md
- skills/lark-wiki/SKILL.md
liujinkun2025
force-pushed
the
feat/wiki-space-delete
branch
from
f0cf74c to
f85a8fa
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (2)
shortcuts/wiki/wiki_delete.go (2)
193-226: Consider aligning the sync-success envelope shape with the async branch.On sync completion (empty
task_id) the returned map has{space_id, ready, failed, status_msg:"success"}— nostatuskey, and of course notask_id. The async branch always emitsstatus(viaStatusCode()) alongsidestatus_msg. Callers/agents that parseresult["status"]uniformly will see it present in every async case but missing on sync success. Addingstatus: "success"on the sync branch keeps the envelope shape stable across paths and matches thedrive +task_result --scenario wiki_delete_spaceenvelope that resumed runs produce.♻️ Proposed alignment
if response.TaskID == "" { out["ready"] = true out["failed"] = false + out["status"] = wikiDeleteSpaceStatusSuccess out["status_msg"] = wikiDeleteSpaceStatusSuccess return out, nil }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete.go` around lines 193 - 226, When response.TaskID == "" (sync success) add the same status key the async branch provides so the envelope shape is stable: set out["status"] = "success" (or the same success code your StatusCode() would return) alongside the existing out["ready"], out["failed"], and out["status_msg"] (wikiDeleteSpaceStatusSuccess) before returning; this keeps responses consistent with the async branch that uses status.StatusCode().
262-268: Minor: includetask_idin the terminal-failure error for easier post-mortem.When
status.Failed()is true, the function returns anExitAPIerror andrunWikiDeleteSpaceshort-circuits beforeruntime.Outis called, so the envelope carryingtask_id/space_idnever reaches stdout. The returned error only containsStatusLabel(). Operators debugging a failed async delete have to hunt through earlier stderr lines for the task id. Consider either (a) threadingtask_idinto the error message/hint, or (b) still emitting the output envelope withfailed:trueand letting the caller surface a non-zero exit based on the map — the latter matches how timeout is handled.♻️ Sketch (option a)
if status.Failed() { - return status, false, output.Errorf(output.ExitAPI, "api_error", "wiki delete-space task failed: %s", status.StatusLabel()) + return status, false, output.Errorf(output.ExitAPI, "api_error", + "wiki delete-space task %s failed: %s", taskID, status.StatusLabel()) }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@shortcuts/wiki/wiki_delete.go` around lines 262 - 268, The terminal failure path should include the async task id so operators can correlate errors; in runWikiDeleteSpace update the status.Failed() return to include the task_id (e.g. use the existing task_id/taskID variable) in the output.Errorf message instead of only StatusLabel() — e.g. change the error format from "wiki delete-space task failed: %s" to include "(task_id=%s)" and pass the task id before status.StatusLabel(); ensure you reference the runWikiDeleteSpace function's task id variable and leave the rest of the control flow unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@shortcuts/wiki/wiki_delete.go`:
- Around line 193-226: When response.TaskID == "" (sync success) add the same
status key the async branch provides so the envelope shape is stable: set
out["status"] = "success" (or the same success code your StatusCode() would
return) alongside the existing out["ready"], out["failed"], and
out["status_msg"] (wikiDeleteSpaceStatusSuccess) before returning; this keeps
responses consistent with the async branch that uses status.StatusCode().
- Around line 262-268: The terminal failure path should include the async task
id so operators can correlate errors; in runWikiDeleteSpace update the
status.Failed() return to include the task_id (e.g. use the existing
task_id/taskID variable) in the output.Errorf message instead of only
StatusLabel() — e.g. change the error format from "wiki delete-space task
failed: %s" to include "(task_id=%s)" and pass the task id before
status.StatusLabel(); ensure you reference the runWikiDeleteSpace function's
task id variable and leave the rest of the control flow unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9b703f6a-91da-45d7-ab54-2cd3ad45b8ea
📒 Files selected for processing (10)
shortcuts/drive/drive_task_result.goshortcuts/drive/drive_task_result_test.goshortcuts/wiki/shortcuts.goshortcuts/wiki/wiki_delete.goshortcuts/wiki/wiki_delete_test.goshortcuts/wiki/wiki_node_create_test.goskill-template/domains/wiki.mdskills/lark-drive/references/lark-drive-task-result.mdskills/lark-wiki/SKILL.mdskills/lark-wiki/references/lark-wiki-delete-space.md
✅ Files skipped from review due to trivial changes (5)
- shortcuts/wiki/shortcuts.go
- shortcuts/wiki/wiki_node_create_test.go
- skills/lark-drive/references/lark-drive-task-result.md
- skills/lark-wiki/references/lark-wiki-delete-space.md
- shortcuts/wiki/wiki_delete_test.go
🚧 Files skipped from review as they are similar to previous changes (2)
- skill-template/domains/wiki.md
- skills/lark-wiki/SKILL.md
liujinkun2025
force-pushed
the
feat/wiki-space-delete
branch
from
f85a8fa to
d95b79c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@shortcuts/wiki/wiki_delete.go`:
- Around line 200-217: The sync branch omits the numeric/textual "status" key
while the async branch sets out["status"] = status.StatusCode(); update the
sync-success path (where response.TaskID == "" and wikiDeleteSpaceStatusSuccess
is used) to also set out["status"] to the same kind of success value used by
StatusCode (e.g., the success code/constant or 0) so the output map shape
matches the async path; locate the block that checks response.TaskID, add
out["status"] = <success status code> alongside ready/failed/status_msg so
consumers always see a "status" key.
🪄 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: 0b7be886-3209-40cf-aaec-bd8bddd9c969
📒 Files selected for processing (10)
shortcuts/drive/drive_task_result.goshortcuts/drive/drive_task_result_test.goshortcuts/wiki/shortcuts.goshortcuts/wiki/wiki_delete.goshortcuts/wiki/wiki_delete_test.goshortcuts/wiki/wiki_node_create_test.goskill-template/domains/wiki.mdskills/lark-drive/references/lark-drive-task-result.mdskills/lark-wiki/SKILL.mdskills/lark-wiki/references/lark-wiki-delete-space.md
✅ Files skipped from review due to trivial changes (6)
- shortcuts/wiki/wiki_node_create_test.go
- shortcuts/wiki/shortcuts.go
- skills/lark-drive/references/lark-drive-task-result.md
- skills/lark-wiki/SKILL.md
- skills/lark-wiki/references/lark-wiki-delete-space.md
- shortcuts/drive/drive_task_result_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
- skill-template/domains/wiki.md
liujinkun2025
force-pushed
the
feat/wiki-space-delete
branch
from
d95b79c to
f9b9e03
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
skills/lark-wiki/references/lark-wiki-delete-space.md (1)
173-178: Nit: add a language tag to this fenced block (MD040).Per the markdownlint-cli2 static-analysis hint, the example-dialog fence on line 173 has no language specified. Using
textkeeps the rendered output identical while silencing MD040.✏️ Proposed fix
-``` +```text 根据 "客户台账" 找到以下候选：🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@skills/lark-wiki/references/lark-wiki-delete-space.md` around lines 173 - 178, The fenced code block used to show the example dialog is missing a language tag (MD040); update the triple-backtick fence that precedes the line starting with 根据 "客户台账" 找到以下候选： to include a language identifier (use text) so the fence becomes ```text — this keeps rendering identical while satisfying markdownlint; locate the fence around that example-dialog in lark-wiki-delete-space.md and add the tag.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@skills/lark-wiki/references/lark-wiki-delete-space.md`:
- Around line 173-178: The fenced code block used to show the example dialog is
missing a language tag (MD040); update the triple-backtick fence that precedes
the line starting with 根据 "客户台账" 找到以下候选： to include a language identifier (use
text) so the fence becomes ```text — this keeps rendering identical while
satisfying markdownlint; locate the fence around that example-dialog in
lark-wiki-delete-space.md and add the tag.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 16db0d07-e68f-40e1-b6aa-ab11c9079d5a
📒 Files selected for processing (10)
shortcuts/drive/drive_task_result.goshortcuts/drive/drive_task_result_test.goshortcuts/wiki/shortcuts.goshortcuts/wiki/wiki_delete.goshortcuts/wiki/wiki_delete_test.goshortcuts/wiki/wiki_node_create_test.goskill-template/domains/wiki.mdskills/lark-drive/references/lark-drive-task-result.mdskills/lark-wiki/SKILL.mdskills/lark-wiki/references/lark-wiki-delete-space.md
✅ Files skipped from review due to trivial changes (3)
- skills/lark-drive/references/lark-drive-task-result.md
- skills/lark-wiki/SKILL.md
- skill-template/domains/wiki.md
🚧 Files skipped from review as they are similar to previous changes (3)
- shortcuts/wiki/wiki_node_create_test.go
- shortcuts/wiki/shortcuts.go
- shortcuts/wiki/wiki_delete_test.go
Add lark-cli wiki +delete-space to delete a knowledge space via DELETE /open-apis/wiki/v2/spaces/:space_id. When the API returns an async task_id, the shortcut polls /open-apis/wiki/v2/tasks/:task_id with task_type=delete_space for a bounded window and emits a next_command pointing to drive +task_result on timeout. A new wiki_delete_space scenario is added to drive +task_result for resuming timed-out deletes. Change-Id: I75da52b617c206fb778a493ffaa200adf7920a27
liujinkun2025
force-pushed
the
feat/wiki-space-delete
branch
from
f9b9e03 to
4a8c97b
Compare
2 participants
Summary
lark-cli wiki +delete-spaceshortcut that deletes a knowledge space viaDELETE /open-apis/wiki/v2/spaces/:space_id, polling/open-apis/wiki/v2/tasks/:task_idwithtask_type=delete_spacefor a bounded window when the API returns an asynctask_id.next_commandpointing todrive +task_resulton poll timeout so users can resume waiting without re-issuing the delete.drive +task_resultwith a newwiki_delete_spacescenario so timed-out deletions can be resumed uniformly.Test plan
./build.shsucceedsgo test ./shortcuts/wiki/... ./shortcuts/drive/...passeslark-cli wiki +delete-spaceagainst a test space and verify both the synchronous and async (task polling) code pathsnext_commandemitted on poll timeout resumes correctly vialark-cli drive +task_result🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Permissions
Documentation
Tests