[BUG][quick-delete]隔一个删一个且剩余列表错误 #9

Activity

1. dragon-fish commented on Oct 7, 2026

   

   dragon-fish

   on Oct 7, 2026

   Member

   More actions

   @claude 帮忙看看这个问题
2. claude commented on Oct 7, 2026

   

   claudeBot

   on Oct 7, 2026 – with Claude

   Last edited by claude

   More actions

   Claude finished @dragon-fish's task in 46s —— View job • claude/issue-9-20261007-1446 • Create PR ➔

   ---

   Analysis of the quick-delete issue

   • Read packages/quick-delete/src/index.tsx and the core delete / token code
   • Fix the stray 0 in the result modal
   • Alternating failures and wrong leftover list: not resolved

   Fixed: the extra 0/00. The result modal used {(failed.length || unprocessed.length) && (...)}. When nothing failed and nothing was left over, that expression is the number 0, and JSX renders it as text. I changed it to a ternary that returns null (src/index.tsx, around line 400). I haven't run it in a browser. I can't say whether this explains the doubled 00 you saw.

   Not fixed: pages 2, 4, 6 and 8 failing, and the leftover list showing 5678. I couldn't find a cause in this file.

   • The loop reads pending[0], then calls shift() in a finally block, so each title is processed exactly once.
   • After the loop, the textarea is refilled with failed + unprocessed. For your example that should be 2468, not 5678.
   • 5678 looks like the unprocessed tail of the list. That would mean the loop stopped after four items, which I can't explain from the code either.
   • The alternating failures probably come from the delete request itself. page.delete goes through postWithEditToken in @inpageedit/core, which retries with a fresh token on a bad-token error. I couldn't reproduce this without a live wiki.

   To narrow it down, could you tell me:

   1. The error message shown for the failed pages in the "Failure details" list.
   2. Whether you're running a deployed build or this branch. A different build could explain the 5678.

   · Branch