fix: correct CraftQueue add recipe behavior for button and work orders#1059
fix: correct CraftQueue add recipe behavior for button and work orders#1059
Conversation
- Bypass CRAFTQ:AddRecipe wrapper in QueueOpenRecipe (3 call sites) and QueueWorkOrders, calling craftQueue:AddRecipe() directly to prevent queue size reset after adding items - Fix FindRecipeByParentRecipeInfo key mismatch: was using 'concentrating' as the 4th key segment but recipeCrafterMap stores keys using 'orderID' (from GetRecipeCraftQueueUID). Sub-recipes were immediately removed every display update because parentCraftQueueItems was always 0. - Add orderID field to ParentRecipeInfo and update CreateParentRecipeInfo to populate it, so FindRecipeByParentRecipeInfo key matches exactly.
Classes/CraftQueue.lua
Outdated
| local aProfitOk = a.recipeData.averageProfitCached ~= nil | ||
| local bProfitOk = b.recipeData.averageProfitCached ~= nil | ||
| if not aProfitOk or not bProfitOk then |
There was a problem hiding this comment.
Please use more verbose variable names. It should be immediately clear what the purpose or content of this is by just looking at the name
There was a problem hiding this comment.
Renamed aProfitOk/bProfitOk to aHasCachedAverageProfit/bHasCachedAverageProfit in FilterSortByPriority for clarity.
Modules/CraftQueue/CraftQueue.lua
Outdated
| CraftSim.CRAFTQ.craftQueue = CraftSim.CRAFTQ.craftQueue or CraftSim.CraftQueue() | ||
| CraftSim.CRAFTQ.craftQueue:AddRecipe({ recipeData = recipeData }) | ||
| CraftSim.CRAFTQ.UI:UpdateQueueDisplay() | ||
| if CraftSim.DB.OPTIONS:Get("CRAFTQUEUE_AUTO_SHOW") then | ||
| CraftSim.DB.OPTIONS:Save("MODULE_CRAFT_QUEUE", true) | ||
| CraftSim.CRAFTQ.frame:Show() | ||
| CraftSim.CRAFTQ.frame:Raise() |
There was a problem hiding this comment.
It seems all those wrapper bypasses do the same.
I would like the wrapper to be updated and accepting an additional optional flag if specific behavior is needed instead of adding indentical wrapper replacements in various places
There was a problem hiding this comment.
The root cause of the original bypass was WoW taint: CraftSim.CRAFTQ is touched by secure callbacks (C_FunctionContainers.CreateCallback for work orders, hooksecurefunc for auction house), which taints the CraftSim.CRAFTQ.AddRecipe reference stored in the global table. Calling it from those contexts was silently swallowed by WoW's taint system — the bypass worked by accident because it never went through the tainted global reference.
netouss
requested review from
Copilot and
derfloh205
and removed request for
Copilot
2 participants
Problem
Two bugs prevented recipes from being added to the CraftQueue:
+ CraftQueue button / QueueOpenRecipe: Calling
CRAFTQ:AddRecipe()(the module wrapper) causedqueueSize=0after the call. The wrapper is called from a protected WoW script boundary (button OnClick) which swallows errors silently.Sub-recipes immediately removed: After a recipe with self-crafted reagents was added, its sub-recipes were removed on the very next display update.
UpdateCountByParentRecipesalways foundparentCraftQueueItems: 0becauseFindRecipeByParentRecipeInfousedconcentratingas the 4th key segment, whilerecipeCrafterMapstores entries keyed byGetRecipeCraftQueueUIDwhich usesorderID.Fix
CRAFTQ:AddRecipewrapper inQueueOpenRecipe(all 3 call sites) andQueueWorkOrders, callingcraftQueue:AddRecipe()directly — same proven pattern.orderIDfield toParentRecipeInfo(populated inCreateParentRecipeInfo).FindRecipeByParentRecipeInfoto useorderID or 0as the 4th key segment, matchingGetRecipeCraftQueueUIDexactly.