Bug? "Black wins by Timeout" too early

In game Jon Ko vs. jacksakura2002 the game result says “Black wins by Timeout”, but that can’t be right. I (black) have just played a move, so white should’ve still had a full 30s byu-yomi period. I’m not even sure whether I’ve heard the “Black wins” before or after I played my last move, which means, white could’ve timed out while it was black’s turn.

White apparently had some connection issues during the game, as the lightning symbol was shown a few (3+) times for 20, 30 seconds or more (I don’t remember exactly). The second time the lightning appeared I paused the game after some seconds, because I wanted to give white a chance to react to the connection issues, but white just kept playing at some point so I ended the pause (pressed “resume”).

Regarding post game chat: I’ve asked white if they resigned, but their “Ya…” came so quickly, I think it was meant as an answer to my previous question.

2 Likes

To me it looks like your opponent timed out on their previous move but they placed it (allowing you to place yours) before the system processed their timeout.

Rather like placing a stone IRL and then having the clock expire before they got their hand over to it.

2 Likes

But I’ve spent some time thinking on my move before the game end was announced. And anyway the system shouldn’t allow the stone to be placed if the player already ran out of time. So something seems off here.

2 Likes

Another easier example 3-sec-move vs. Alexej Kolendo

The last stone is placed too late but still appears.

My game was different though. In the 9x9 game white’s move went through although white lost by timeout. In my game it was me (black) that played a move when white timed out (20 seconds after white’s last move).

But I’ve looked at the game details via the API and apparently white spent 31 seconds on their last move, so it could still be possible that white timed out on that move, if they didn’t have any more periods. With the pause I don’t know how to exactly figure out how many periods they had left.

So maybe you’re right, white might have timed out correctly and it just took the server 20 seconds to figure that out, which caused the confusion. Or it took the server 20 seconds to notify my client and it still accepted my move.

data
Move Column Row Time per move Black seconds White seconds Black spent White spent Notes
1 15 3 8,813 8.81 8.81
2 3 15 1,774 1.77 8.81 1.77
3 16 15 5,863 5.86 14.68 1.77
4 3 2 3,556.5 3.56 14.68 5.33
5 14 15 5,106.5 5.11 19.78 5.33
6 2 8 6,782.5 6.78 19.78 12.11
7 5 16 10,962 10.96 30.74 12.11
8 5 15 3,233 3.23 30.74 15.35
9 6 15 2,809 2.81 33.55 15.35
10 5 14 2,004 2 33.55 17.35
11 4 17 4,765 4.77 38.32 17.35
12 4 16 11,453.5 11.45 38.32 28.8
13 6 16 40,617.5 40.62 78.94 28.8
14 3 17 5,557 5.56 78.94 34.36
15 3 3 15,400.5 15.4 94.34 34.36
16 2 3 7,780.5 7.78 94.34 42.14
17 2 2 35,588 35.59 129.92 42.14
18 2 4 24,328 24.33 129.92 66.47
19 4 2 38,208 38.21 168.13 66.47
20 3 1 15,411.5 15.41 168.13 81.88
21 4 1 8,476.5 8.48 176.61 81.88
22 2 1 33,873.5 33.87 176.61 115.75
23 4 3 29,323.5 29.32 205.93 115.75
24 7 13 10,008 10.01 205.93 125.76
25 11 16 47,202.5 47.2 253.14 125.76
26 16 2 23,932.5 23.93 253.14 149.69
27 16 3 31,841.5 31.84 284.98 149.69
28 15 2 3,694 3.69 284.98 153.39
29 13 2 13,985 13.99 298.96 153.39
30 14 2 3,682.5 3.68 298.96 157.07
31 14 3 1,357 1.36 300.32 157.07
32 13 1 2,899 2.9 300.32 159.97
33 17 2 1,910 1.91 302.23 159.97
34 17 1 3,237 3.24 302.23 163.21
35 14 1 2,955 2.96 305.18 163.21
36 15 1 3,593.5 3.59 305.18 166.8
37 12 1 6,567 6.57 311.75 166.8
38 14 0 3,550 3.55 311.75 170.35
39 12 2 3,235 3.23 314.99 170.35
40 15 9 51,244.5 51.24 314.99 221.6
41 1 2 13,490.5 13.49 328.48 221.6
42 1 1 24,823.5 24.82 328.48 246.42
43 16 11 65,905 65.91 394.38 246.42
44 15 11 100,604 100.6 394.38 347.02
45 16 10 8,758 8.76 403.14 347.02
46 15 10 14,195.5 14.2 403.14 361.22
47 16 9 50,378 50.38 453.52 361.22
48 15 13 10,393.5 10.39 453.52 371.61
49 14 12 45,277.5 45.28 498.79 371.61
50 15 12 31,494.5 31.49 498.79 403.11
51 13 7 51,701 51.7 550.5 403.11
52 17 13 78,646 78.65 550.5 481.75
53 15 8 5,909.5 5.91 556.41 481.75
54 17 15 21,357 21.36 556.41 503.11
55 17 16 21,661 21.66 578.07 503.11
56 16 14 17,988.5 17.99 578.07 521.1
57 18 15 10,036.5 10.04 588.1 521.1
58 15 15 6,573.5 6.57 588.1 527.67
59 16 16 42,689 42.69 630.79 527.67
60 15 16 23,016 23.02 630.79 550.69
61 14 14 26,138.5 26.14 656.93 550.69
62 15 14 16,378 16.38 656.93 567.07
63 17 14 2,346.5 2.35 659.28 567.07
64 14 16 18,174 18.17 659.28 585.24
65 12 15 60,587.5 60.59 719.86 585.24
66 14 13 55,671 55.67 719.86 640.91
67 13 9 39,361 39.36 759.22 640.91
68 13 13 86,248 86.25 759.22 727.16 Paused during this move
69 12 14 12,289.5 12.29 771.51 727.16 Unpaused during this move
70 13 11 23,086 23.09 771.51 750.24
71 5 11 80,704 80.7 852.22 750.24
72 3 11 37,644.5 37.64 852.22 787.89
73 4 9 47,252.5 47.25 899.47 787.89
74 8 3 63,864.5 63.86 899.47 851.75
75 2 9 21,739.5 21.74 921.21 851.75
76 3 9 24,240.5 24.24 921.21 875.99
77 3 10 38,422 38.42 959.63 875.99
78 3 8 78,843 78.84 959.63 954.84
79 2 10 7,008 7.01 966.64 954.84
80 3 12 19,862.5 19.86 966.64 974.7
81 4 10 44,517 44.52 1,011.16 974.7
82 4 5 5,785 5.79 1,011.16 980.48
83 6 4 39,630.5 39.63 1,050.79 980.48
84 8 6 48,510 48.51 1,050.79 1,028.99
85 6 6 4,188.5 4.19 1,054.98 1,028.99
86 6 2 28,532.5 28.53 1,054.98 1,057.53
87 6 3 46,602 46.6 1,101.58 1,057.53
88 13 6 17,003 17 1,101.58 1,074.53
89 12 6 18,961 18.96 1,120.54 1,074.53
90 13 3 11,212.5 11.21 1,120.54 1,085.74
91 12 4 59,943 59.94 1,180.48 1,085.74
92 13 4 82,975.5 82.98 1,180.48 1,168.72
93 13 5 6,296.5 6.3 1,186.78 1,168.72
94 14 8 113,925.5 113.93 1,186.78 1,282.64
95 14 7 11,202.5 11.2 1,197.98 1,282.64
96 16 8 14,406.5 14.41 1,197.98 1,297.05
97 15 7 7,781.5 7.78 1,205.76 1,297.05
98 17 8 5,900 5.9 1,205.76 1,302.95
99 17 6 69,417 69.42 1,275.18 1,302.95
100 18 11 31,437.5 31.44 1,275.18 1,334.39
101 17 11 28,612.5 28.61 1,303.79 1,334.39
102 18 10 17,242.5 17.24 1,303.79 1,351.63
103 9 10 53,613 53.61 1,357.41 1,351.63
104 14 5 14,130 14.13 1,357.41 1,365.76
105 14 6 9,411.5 9.41 1,366.82 1,365.76
106 16 5 32,169.5 32.17 1,366.82 1,397.93
107 17 5 28,593.5 28.59 1,395.41 1,397.93
108 14 4 44,264 44.26 1,395.41 1,442.19
109 17 4 26,637 26.64 1,422.05 1,442.19
110 12 3 25,954 25.95 1,422.05 1,468.15
111 9 2 27,633 27.63 1,449.68 1,468.15
112 11 2 29,968.5 29.97 1,449.68 1,498.12
113 11 1 3,929.5 3.93 1,453.61 1,498.12
114 11 4 6,241.5 6.24 1,453.61 1,504.36
115 12 5 5,455.5 5.46 1,459.07 1,504.36
116 12 0 31,094.5 31.09 1,459.07 1,535.45
117 10 1 23,058 23.06 1,482.12 1,535.45
2 Likes

A similar game. This time black lost on timeout after playing a move (but today there was no pause during the game, though I remember slight connection issues for my opponent/black).

Looking at the move times via the API it seemingly happened like this:

  1. Black was on their last byo-yomi period and exceeded it by 8 seconds
  2. Black’s move was placed on the board
  3. White took 14 seconds to respond
  4. Immediately after white responded the result was announced. (“White wins by Timeout”)

So my guess is: Black timed out correctly, but both players could still place a stone before the result was actually announced.

Anyway there’s something odd going on.

3 Likes

Is it possible that the disconnect timer doesnt care whos turn it is? In that case you could time out because of connection issues (as opposed to the game clock) even on your opponents turn.
I havent checked this, its just an idea.

The disconnection timer runs for five minutes in those default live games and restarts for every disconnection AFAIK. The connection issues weren’t that big, so I don’t think that was the issue in yesterday’s game. And I think then the result would be “wins by Disconnection” instead of “wins by Timeout”.

1 Like

Are you thinking “each of the players’ clients was behind the real situation - the server had already decided black had timed out, but the players’ clients didn’t find out yet, so they got to play another turn”.

This seems conceivable. @anoek ?

I don’t have a clue how server and client are communicating at the end of the game, but I think the server shouldn’t allow more moves if it already decided the game is over. (Of course the clients also shouldn’t allow more moves once they know the game is over).

1 Like

… right, but remember that there is a multi-second time lag between what each knows, and yet each has to respond in sub-second timing.

The trick is to present the illusion that they are in continuous agreement to the user. That’s what we’re working on here.


Of course - only anoek does. I made a hyopothesis, I was asking if it fits what you saw.

2 Likes

Good point, sadly I didn’t notice that black was running out of time. I remember that I noticed at some point that they were down to their last period, but I didn’t pay attention to their 30 seconds counting down. I was (most likely) looking at the board until I saw my opponent’s move, then thought about how to respond, then I played my move and then I heard the announcement surprisingly fast, so fast I can’t say whether it was before I played or after that.

If I hadn’t checked the API to see how long it took my opponent to play, I wouldn’t believe the result to be correct. I just hope the API is providing correct numbers, but I don’t really have a reason to doubt that.

1 Like