Questie

Questie

116M Downloads

some error after use return stone in bcc

SunnyJang38 opened this issue ยท 3 comments

commented

3x Questie\Modules\Libs\QuestieLib.lua:257: bad argument #1 to 'unpack' (table expected, got nil)
[string "=[C]"]: in function unpack' [string "@Questie\Modules\Libs\QuestieLib.lua"]:257: in function GetTbcLevel'
[string "@Questie\Modules\Libs\QuestieLib.lua"]:176: in function GetColoredQuestName' [string "@Questie\Modules\QuestLinks\Link.lua"]:66: in function GetQuestHyperLink'
[string "@Questie\Modules\QuestLinks\ChatFilter.lua"]:38: in function filterFunc' [string "@Prat-3.0-3.9.1\services\chatsections.lua"]:49: in function <Prat-3.0\services\chatsections.lua:41> [string "@Prat-3.0-3.9.1\services\chatsections.lua"]:340: in function SplitChatMessage'
[string "@Prat-3.0-3.9.1\addon\addon.lua"]:639: in function <Prat-3.0\addon\addon.lua:613>
[string "=(tail call)"]: ?
[string "@FrameXML\ChatFrame.lua"]:2930: in function `ChatFrame_OnEvent'
[string ":OnEvent"]:1: in function <[string ":OnEvent"]:1>

Locals:
(*temporary) = nil
(*temporary) = "table expected, got nil"

commented

Hey @SunnyJang38 are you using the TBC version of Prat? https://www.curseforge.com/wow/addons/prat-tbc

commented

If questId received from chat is not in Questie's DB, this happens, because:

ChatFilter.Filter( ) does only regexp validation for received link and tonumber() for parsed questId. IMO it should also check that questId is existing one - i.e. there is a quest for the questId. OR some of functions called after in execution path should:

function QuestieLink:GetQuestHyperLink(questId, senderGUID) doesn't validate questId before calling
function QuestieLib:GetColoredQuestName(questId, showLevel, showState, blizzLike) which doesn't validate it either before calling
function QuestieLib:GetTbcLevel(questId) which doesn't validate it either before calling
QuestieDB.QueryQuest(questId, "questLevel", "requiredLevel") which is in practice handle.Query(id, ...) inside function QuestieDBCompiler:GetDBHandle(data, pointers, skipMap, keyToRootIndex, overrides).

handle.Query(id, ...) can return nil if pointers[id] and overrides[id] are both nil.
This results unpack(nil).

IMO it doesn't matter if Prat possibly mangles link data or not. Or if somebody is "attacking" by sending malformed link. It is receiver's job to validate data and act gracefully to it.

commented

Questie heavily relies on the fact that the questIds it handles exist in the datebase. So we didn't add such checks on purpose, because they would have to be all over the place (basically every time something is queued from the database).

But if thinking about it from the view of "only external data can mess something up" it makes absolutely sense to add checks add places where external data comes in. That is in general the chat filter, so I agree that it should check if the questId sent is in our database.