`dbQuery` callback arguments cannot be functions

[Rilot06]

Describe the bug

When you use dbQuery as async with a callback, and you want to pass a function in the callbackArguments parameter table, it will become nil in the callback function.

function sayHello()
    print("Hello!")
end

dbQuery(function(qh, func)
    local result = dbPoll(qh, 0)

    func() -- You will get an error here, func will be nil
end, {sayHello}, dbConnection, "...")

Steps to reproduce

1. Use async dbQuery with a callback
2. Use the callbackArguments param, try to pass a function in that table
3. Check the passed arg in the callback function, it will be nil

Version

Server: 1.6-release-23312

Additional context

I guess it happens because you can't reference that function after, even though it's the same resource, not sure how easy (or possible at all) a fix would be.
You could handle it in Lua every time, by storing the function in a global/top scope table and pass the index reference the function from that table (or even sending the function name and using _G), but it quickly becomes a hassle.

Relevant log output

Security Policy

• I have read and understood the Security Policy and this issue is not security related.

[ArranTuna]

This is a feature request not a bug report because nobody in years has ever wanted to pass a function like this, there's just no need for it.

[Rilot06]

This is a feature request not a bug report because nobody in years has ever wanted to pass a function like this, there's just no need for it.

"callbackArguments: An optional table containing extra arguments to be sent to the callback function."
nowhere in mta wiki it is mentioned that it couldn't handle passing functions as callback args. nobody reporting it before doesn't mean it's on purpose, this is just a stupid excuse. i don't care that much if it's not fixed, but calling it a feature request is simply dumb

[ArranTuna]

Simply dumb? Your example is simply dumb when you could just call sayHello() instead of func() give an actual use case where a function needs to be passed as an argument, because I can't see one.

Anyway, I asked codex to find an issue to fix and it went and chose this one, it's made a pull request so now I'm installing visual studio to build MTA and see if this PR works.

[ArranTuna]

So codex made a PR for this that works. Though unfortunately while testing it different ways it crashed the server when passing a function in setTimer (though client side it worked fine) here is the work it did and the 2 newer commits it did trying to fix it if anyone is interested because I can't be bothered getting it to try any further. Maybe when codex is updated to GPT5 it will be better - ArranTuna#3

[Rilot06]

Simply dumb? Your example is simply dumb when you could just call sayHello() instead of func() give an actual use case where a function needs to be passed as an argument, because I can't see one.

It's not hard to think of an actual use case, but I wouldn't expect more from someone who tries to fix it with an AI agent.
For example having a function that queries the database, does some parsing on the selected data, then passes the parsed data to the callback function, which is passed in DYNAMICALLY to the function, since there is no async/await...

function loadSomething(id, callback)
    dbQuery(function(qh, callback)
        local result = dbPoll(qh, 0)
        -- do some parsing, other stuff, whatever
        callback(parsedResult)
    end, {callback}, dbConnection, "SELECT * FROM whatever WHERE id = ?", id)
end

loadSomething(1, function(data)
    -- do something here
end)

loadSomething(2, function(data)
    -- do something else here
end)

And no, using the same callback function (like a global sayHello as you said) is not the same, since there are scenarios where you have to do different things with the loaded data at different times, and no, copy pasting the dbQuery and parsing it again isn't a great solution to this. :)

[MegadreamsBE]

Simply dumb? Your example is simply dumb when you could just call sayHello() instead of func() give an actual use case where a function needs to be passed as an argument, because I can't see one.

It's not hard to think of an actual use case, but I wouldn't expect more from someone who tries to fix it with an AI agent. For example having a function that queries the database, does some parsing on the selected data, then passes the parsed data to the callback function, which is passed in DYNAMICALLY to the function, since there is no async/await...

function loadSomething(id, callback)
dbQuery(function(qh, callback)
local result = dbPoll(qh, 0)
-- do some parsing, other stuff, whatever
callback(parsedResult)
end, {callback}, dbConnection, "SELECT * FROM whatever WHERE id = ?", id)
end

loadSomething(1, function(data)
-- do something here
end)

loadSomething(2, function(data)
-- do something else here
end)

And no, using the same callback function (like a global sayHello as you said) is not the same, since there are scenarios where you have to do different things with the loaded data at different times, and no, copy pasting the dbQuery and parsing it again isn't a great solution to this. :)

If statements exist for a reason. In your example I don't see a reasonable use-case for this. You can always pass the name of your function as a string, then later on call it through _G[stringHere], if you need it. Also, what if I delete the function? What happens then? The pointer, which is what we'd store, becomes invalid now. It's not worth it, and too high of a risk (memory violation, memory leaks, etc).

Lua is simply not designed to handle this.

[Rilot06]

If statements exist for a reason. In your example I don't see a reasonable use-case for this.

If statement for what lol

You can always pass the name of your function as a string, then later on call it through _G[stringHere], if you need it.

Yeah, that's the exact same thing I said in the issue (if you would have read it, you would know), and I also said it's a shitty workaround.

Also, what if I delete the function? What happens then? The pointer, which is what we'd store, becomes invalid now. It's not worth it, and too high of a risk (memory violation, memory leaks, etc).

Lua is simply not designed to handle this.

I could argue the same about the actual dbQuery's callback, or a setTimer's callback, you could simply delete that too..

As I said, it's not the most important thing, but then update the wiki to say that not all variable types can be passed as callback args. Calling this a "feature request" is simply dumb.