Strange glitch when redeeming batch of keys on bot with Forwarding and Distribution enabled - multiple attempts to redeem same key on same bot.
#1504
Comments
Rudokhvist
added
🐛 Bug
JustArchi
added
🐍 Not a bug
It wasn't, you have no status that determines the key is used, only certain statuses determine that, e.g. invalid key, duplicate key or redeemed key, none of those is included in your log, so ASF properly tries to redeem the same key on different bots, this is exactly how forwarding + distribution works, as per the wiki.
This includes a possibility of running into the same bots, because the distribution went from bot6 and not bot3. ASF had to finish the queue alphabetically first before going back to the beginning and trying again. Even with the first Nothing you described above is a bug. |
JustArchi
added
✨ Enhancement
|
See if 09f754e fixed redeeming on the same bots in second queue. |
JustArchi
added
the
🟢 Low priority
No, it's not fixed in latest appveyor build, result is the same as above.
No, it tries to redeem the same key on same bot, which is outright wrong. If redeeming failed - chances that consequent redeeming of the same key is very small, only possible scenario I can imagine is if redeeming ended up with timeout, i.e. when first redeeming never actually happened. So with all respect to you - this is a bug. |
It's not a bug if the function works exactly as intended and written, the fact that we're now trying to make bots skip further queues is enhancement to redeem feature. Can you try 8668ab8? |
Still the same as before.
Absolutely every program works exactly as written, and you know it well. And if you believe it's intended behaviour, could you please answer one simple question for me? Let's say I have two bots, and key for a game that both bots already have. First bot has both Some day I should completely re-factor redeeming routine and do a PR, because it seems it's so messed that even you have no idea how it works. Not this week though. |
|
I won't get into argument with you because I have better stuff to do than proving my point. Instead you can check if c67f380 fixed your issue, or not if you can't behave like a human being. |
|
With latest appveyor build (1268-master) this bug is kinda "fixed", but something else is broken - the rest of keys after this damned |
|
e077622 should fix it for good, feel free to try. |
|
Now it looks almost perfect: I still don't understand this behavior: Why it switches to |
Yes, we go through all the bots that can redeem it, and if no bot is able to, we reset back to beginning with the next key. You can't say that any other bot makes "more sense", since we just ran out of them all. |
|
Thought so. But why reset if it could just continue from the bot where last redeeming attempt was made? Or maybe from the one right after it in queue, unsure what fits better to "forwarding+distributing" logic. |
|
That would involve saving "last success" bot in the queue, the loop is not working like that, while we have a key to redeem, it enumerates over all bots (starting with the target one), and once we run out of them we change the key to avoid infinite loop. It's a matter of implementation right now, we enumerate bots for a key, not keys for a bot. |
|
Okay, if it's up to implementation, it's definitely not worth the efforts to change it. Maybe if I'll decide to refactor it, I'll try another approach. |
|
Thank you once again for fixing it ❤️ |
Bug report
Description
I have 9 bots running, one of them is has both
ForwardingandDistributingenabled inRedeemingPreferences. I send a batch of keys to this bot, and under some condition it tries to redeem same key on same bot twice. Below is a copy&paste of chat with this issue (I replaced bot names for paranoia reasons, keys are all used, so it's safe to post them, bot8 = my main account, bot3 = account I'm chatting with):❗❗❗Take a look at what happening with
32X5I-A9H6A-N734Dkey - it was redeemed twice on multiple bots, this should not happen.Expected behavior
There should be only one attempt to redeem one particular key on one particular bot.
Current behavior
There were two attempts to redeem one particular key on one particular bot
Steps to reproduce
I was unable yet to reliably reproduce it with small amount of keys and bots, but I tried to redeem the same batch of keys as above multiple times (with intervals to allow
RateLimitedbots to become available again) and got the same result every time, so it's reproducible at least in given environment.Full log.txt recorded during reproducing the problem
Global ASF.json config (if using one)
{ "AutoRestart": false, "ConnectionTimeout": 250, "ConfirmationsLimiterDelay": 20, "CurrentCulture": "en-US", "Headless": true, "IdleFarmingPeriod": 1, "IPC": true, "IPCPassword": "***", "Statistics": false, "SteamMessagePrefix": "/pre ", "SteamOwnerID": 76561198056109653, "UpdateChannel": 0, "WebLimiterDelay": 400BotName.json config of all affected bot instances (if more than one)
{ "Enabled": true, "AcceptGifts": true, "BotBehaviour": 24, "HoursUntilCardDrops": 0, "SendTradePeriod": 12, "LootableTypes": [ 0, 1, 2, 3, 4, 5, 6, 7, 8 ], "RedeemingPreferences": 3, "SteamUserPermissions": { "76561198056109653": 3, }, "TradingPreferences": 1, "SteamPassword": "***", "SteamLogin": "***", "SteamMasterClanID": ***The text was updated successfully, but these errors were encountered: