Improper handling of captured stones (server)

[rocketinventor]

After you capture an area with the other player's stones (white), the board looks like this: However, if you click in it, it places a stone but, instead of proceeding normally, you end up playing for white for several moves (and can only play where white is allowed to go)!!! Traceback always looks something like this:

10.100.1.1 - - [23/Feb/2017 20:49:32] "POST /prediction HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask_cors/extension.py", line 188, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask_cors/extension.py", line 188, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/ubuntu/workspace/.betago/lib/python2.7/site-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/ubuntu/workspace/betago/betago/model.py", line 56, in next_move
    self.bot.apply_move('b', (row, col))
  File "/home/ubuntu/workspace/betago/betago/model.py", line 110, in apply_move
    self.go_board.apply_move(color, move)
  File "/home/ubuntu/workspace/betago/betago/dataloader/goboard.py", line 157, in apply_move
    raise ValueError('Move ' + str(pos) + 'is already on board.')
ValueError: Move (5, 13)is already on board.

[macfergus]

I think you figured out the root cause in #27. I'm going to close this bug as a dupe for now

[rocketinventor]

Update: The x,y swap and described in #27 was probably the cause.

I'm fairly certain that this #27 is not the root cause.

~~I was playing a very successful game against the demo bot where I captured many opponent stones. My current board looks like this:~~ Several times throughout, I got error #30. Instead of fully switching to white (where white stones are shown on hover), it only partially switched and is still showing the hover-preview for black but placing and evaluating white stones.

~~My hypothesis is that BetaGo is not recognizing areas where stones have been captured as playable. To prove my hypothesis (and that #27 is not the cause of this issue), I played in all of the areas that had been previously played (please note that they were processed as white moves due to the issues described in #30)~~

[rocketinventor]

In a recent game, I was able to play over several stones that were captured by BetaGo as well as several stones that I captured from BetaGo without any error.