Closed Spectrum2k closed 1 year ago
M4rlus
commented
1 year ago @eartharoid maybe use uuids for tickets and remove the ticket number completely Edit: I looked it up, the best solution seems like to add a secondary key with auto increment. Otherwhise you have to make it a non async function, that would result in waiting issues with the bot.
RooRay
commented
1 year ago @eartharoid maybe use uuids for tickets and remove the ticket number completely
Edit:
I looked it up, the best solution seems like to add a secondary key with auto increment.
Otherwhise you have to make it a non async function, that would result in waiting issues with the bot.
Or just queue up requests so the bot responds to them one at a time, Discords API latency which is fairly high in comparison to the bots latency means that the bot could spend an extra bit doing that and the average user likely won't notice
eartharoid
commented
1 year ago maybe use uuids for tickets and remove the ticket number completely
Tickets already have a unique ID as the primary key, it's the channel ID. The number is a secondary more user-friendly ID.
I looked it up, the best solution seems like to add a secondary key with auto increment
As far as I can tell, it's impossible to use AUTO_INCREMENT in a way that would allow guilds to have their own counter.
Or just queue up requests so the bot responds to them one at a time, Discords API latency which is fairly high in comparison to the bots latency means that the bot could spend an extra bit doing that and the average user likely won't notice
I thought of this too. It could be possible to create a queue for each guild but I'm not sure how to do that, especially in a way that doesn't negatively impact performance more than necessary. It would need only to affect the postQuestions function, and the bot would need to defer the reply before queueing the interaction;
It already takes undesirably long for the bot to reply with the "Your ticket has been created" message, so I don't want to make it any slower.
I also thought about transactions/locking, but this would need to block all reads and writes on the tickets table, which I'm not sure how to do, and that would definitely slow things down.
There's also OCC, but I don't see how that can work in this situation.
I think a simpler solution is possible:
There are currently over 250 lines between reading and writing with several Promises being awaited in between.
The second could be moved to just after the first, and use a non-locking transaction to update the row with the rest of the data (the channel, opening message etc). This would require changing the primary key from channelId to (guildId, number).
It would (probably, I don't know if it actually makes a difference) be even better if the two queries were combined,
INSERT INTO tickets (
number
)
VALUES (
SELECT number FROM (SELECT MAX(number) + 1 AS number FROM tickets WHERE guildId = '$guildId') AS T
);
This should work, but I don't think it's possible in Prisma without using $queryRaw.
Alternatively, just catch the error and retry, although that's not very elegant as the channel name will be wrong.
M4rlus
commented
1 year ago my 30 second reply: just remove the id thing completely and use the rich presence for ticket count xd bc there is no way to make this nice and without errors or feature removal.
either you remove it completely or you try to fix it which will cause performance issues or otherwhise you remove the function to let the user set a starting id
eartharoid
commented
1 year ago Loading and storing the ticket count for each guild at startup like member and category counts is a good option.
Is there an existing issue for this?
Current Behavior
If users create many tickets at one time, tickets are created with the same ID, and only one ticket can work (other tickets give errors during any interactions).
Expected Behavior
Tickets IDs should not be duplicated.
Steps To Reproduce
Environment
Anything else?
Logs:
Interaction on "bad" ticket: