PokeWalker errors while dowsing

Playing on Chrome, desktop. Multiple tabs open but only one PokeWalker tab. During a dowsing attempt, sometimes the PokeWalker will freeze completely. I have run into this issue with a few variations; I will update with new posts when I catch the other ones as I only ran into one today. This specific instance - I had searched one piece of grass, was told the item was near, then searched the grass next to it and the PokeWalker froze. I caught two AJAX responses: First request: { "pos": 0, "mutex": "6616b9b17291d" } Response: { "ok": true, "turns": 1, "response": "It's near!" } Second request: { "pos": 1, "mutex": "6616b9b17291d" } Response: { "ok": false, "error": "Not enough Watts" } Seems to me the server "forgot" I was in the middle of a dowsing attempt, tried to start a new one (I didn't have enough Watts), and the code block for the middle of the attempt was still looping and didn't know how to handle the error, essentially freezing the Walker. Edit: Looking at the source code, I see there is an error handler for failed requests, although it only seems to check if the player's inventory is full. I assume this is for if the player has multiple tabs open or other race conditions? Similarly, the other instance I referenced seems like it tries to start another dowsing attempt (when I have enough Watts), and regardless of finding the item or not I lose 6 Watts instead of 3. Additionally, sometimes the item is revealed in searched grass patches. Will update with more details if I encounter it again.

I've also just had an attempt that went the other way: I had only one turn to find an item before the item revealed itself. Request sent: { "pos": 0, "mutex": "661a2076007d9" } Response: { "ok": true, "turns": 0, "response": "Nothing found...", "reveal": 1 } Unfortunately I clicked off of the dowsing attempt in the PokeWalker before I realized what happened, but as seen in the requests list on the left in the screenshot the previous attempt I found an item (item.mp3 was requested from the server to play for it), then the next request was the one turn dowse response from the server. After refreshing the PokeWalker page, my 3 Watts for the dowsing attempt were refunded.

Here's an issue where I had three attempts: First request: { "pos": 0, "mutex": "66215522a9c61" } Response: { "ok": true, "turns": 1, "response": "It's far away..." } Second request: { "pos": 2, "mutex": "66215522a9c61" } Response: { "ok": true, "turns": 1, "response": "It's near!" } Third request (which I shouldn't have in a dowsing attempt): { "pos": 3, "mutex": "66215522a9c61" } Response: { "ok": true, "turns": 0, "response": "Nothing found...", "reveal": 1 } Again, I think the same issue: the server forgot I was dowsing between the first and second requests. Second request started another dowsing attempt - I had another 3 Watts in this instance, so instead of failing successfully did so, which is evident by the item changing positions (if it was in the 2nd patch of grass the whole time, the first request would have responded with "It's near!"). I didn't get a screenshot of it this time either, apologies, but returning to the menu the PokeWalker reports I have 7 Watts; refreshing it now reports 4. In the past starting a dowsing attempt with these "phantom" Watts also freezes the Walker, assumably for the Not Enough Watts error. Edit: Additional Screenshot This time the item is seen behind a chosen grass patch. I chose that patch on the first turn and the item moved behind there after another attempt was falsly started. I also did not refresh after the attempt finish to reupdate my Watt count and can confirm I get the Not enough Watts AJAX request failure on the next attempt, freezing the walker like the first post example.

I appreciate the effort that's gone into this. The tricky part is figuring out whether it was the server, or the client, that forgot what the game state should be. This is partially because there's actually no difference between the first and second attempts' payloads, they both look the same. Perhaps I can adjust this by having "attempt: 1" or "attempt: 2" in the payload, so that way if the client sends "attempt: 2" when the server doesn't think there's a Dowsing game going on, it can at least detect that and prevent confusing issues. (It might still deplete the 3W cost, but at least it won't break in such weird ways!) That'll at least prevent weirdness, but the cause of the weirdness remains unknown... It might be a similar issue to the EggSweeper games "losing" a step of progress, for some reason. A desync error. I really don't know how or why these are happening, and they're basically random which makes it a nightmare to debug...

So in times like these, where I'm confused what's happening with my current code, I like to go high level and write pseudocode, and sometimes the steps I expect the user to take, assuming no errors or issues. Here's how I understand the dowsing process should run and the psuedocode for if I was writing it: Pokewalker dowsing steps: 1. Player clicks on dowsing minigame 2. Minigame starts 3. Player clicks on a patch of grass 4. Pokewalker reports whether item is found, near, or far. Decrements one turn if item was not found. 5. Player clicks on a patch of grass, if item wasnt found 6. Pokewalker reports whether item was found or not 7. Player clicks again to return to menu. Sorry if that's hard to follow: indenting is hard in forum posts. Anyways, the main difference here I'd like to point out is I suggest having a "start" request for the minigame, that's different from the turns from searching grass. That way, the server would only recieve turn requests from the client after starting and wouldn't mistake it for a new dowsing attempt. If the user attempts a new one by opening a new PokeWalker window or by refreshing, etc. the server would recieve the new attempt request and drop the old one. Edit: Sorry, it actually wouldn't drop the old attempt, if they were both open. But it would track them separately. So in theory the user could open a new window and if they have enough Watts could do two seperate attempts simultaneously, if both attempts have a unique identifier like the mutex string sent. It's weird behaviour, but I don't really think an issue (unless the user only has one open inventory space, and both attempts find an item, which I think was the intent with the check for inventory space in the current error handler)