Large folder copies lose ~45% of items: simulator drops burst CopyInventoryItem requests; pace item copies (flow control) #538

New issue

Closed

opened 2026-10-08 05:52:06 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-08 05:52:06 +00:00

Owner

Symptom (alt-account stress test, 2026-10-08): copying a folder of 40,457 items in 14,592 folders produced two copies.

	folders	items
source	14,592	40,457
copy 1	14,592 (all)	23,387
copy 2	14,592 (all)	22,331

Nothing was lost: the source is intact, there are no duplicate ids, and Lost and Found, Trash and the orphan counts are unchanged.

Cause: copy_inventory_category_content (llinventoryfunctions.cpp ~508) sends one reliable UDP CopyInventoryItem per item (copy_inventory_item, llviewerinventory.cpp:1335), all at once as each folder's AIS create completes.

The viewer's message stats show failed_resends 0, so every message was sent and acked.
The viewer's model held all 40,457 source items.
So the simulator accepted about 40k item-copy requests and silently didn't perform about 45%, almost certainly its per-agent inventory-operation throttle. Folders (AIS) all made it.
This is stock LL behaviour; every LL-based viewer copies this way.

Fix: pace the item copies (flow control only).

Keep at most N item copies outstanding (start around 25 to 50). Send the next one when an earlier one's completion callback fires (the LLInventoryCallback registered per copy).
The messages keep the same content and the same order. No batching, no automatic retries (owner's inventory-safety rule).
After a timeout, report any copy whose callback never fired ("N items could not be copied") instead of failing silently. Do not resend automatically.
Show progress during big copies.
Apply the same pacing anywhere else that bulk-sends item copies or creates, such as Paste or Ctrl-drag copy of large selections.

Done when: the same 40k-item copy comes out complete (or reports exactly what failed), and small copies feel the same as before.

**Symptom (alt-account stress test, 2026-10-08):** copying a folder of 40,457 items in 14,592 folders produced two copies. | | folders | items | |---|---|---| | source | 14,592 | 40,457 | | copy 1 | **14,592** (all) | 23,387 | | copy 2 | **14,592** (all) | 22,331 | Nothing was lost: the source is intact, there are no duplicate ids, and Lost and Found, Trash and the orphan counts are unchanged. **Cause:** `copy_inventory_category_content` (llinventoryfunctions.cpp ~508) sends one reliable UDP `CopyInventoryItem` per item (`copy_inventory_item`, llviewerinventory.cpp:1335), all at once as each folder's AIS create completes. - The viewer's message stats show `failed_resends` 0, so every message was sent and acked. - The viewer's model held all 40,457 source items. - So the simulator accepted about 40k item-copy requests and silently didn't perform about 45%, almost certainly its per-agent inventory-operation throttle. Folders (AIS) all made it. - This is stock LL behaviour; every LL-based viewer copies this way. **Fix: pace the item copies (flow control only).** - Keep at most N item copies outstanding (start around 25 to 50). Send the next one when an earlier one's completion callback fires (the `LLInventoryCallback` registered per copy). - The messages keep the **same content and the same order**. No batching, no automatic retries (owner's inventory-safety rule). - After a timeout, report any copy whose callback never fired ("N items could not be copied") instead of failing silently. Do not resend automatically. - Show progress during big copies. - Apply the same pacing anywhere else that bulk-sends item copies or creates, such as Paste or Ctrl-drag copy of large selections. **Done when:** the same 40k-item copy comes out complete (or reports exactly what failed), and small copies feel the same as before.

sky_line added the

labels

2026-10-08 05:52:06 +00:00

sky_line added this to the Slipstream project

2026-10-08 05:52:06 +00:00

sky_line referenced this issue