Tournament results bug?

Oh, nice to see this being looked into ! ^^

I had noticed this before at various times over the past nearly 2 years of playing double-elimination tournaments, but I think hadn’t made a bug report yet.

I think some others have asked about it in the Help channel or on the forums, though, perhaps.

Yes, I’ve seen it before in sitewide double-elimination tournaments on more than a few occasions, with at least one with a player ranked 11-16k or so who should have placed second, placing fourth.

There were other occasions too, which I don’t recall the link/tournaments of anymore, but involved DDK players, which seemed to me to likely be penalising lower-rated players (something like mixing in a McMahon-style penalty) who would otherwise place higher.

I recall various cases in which a DDK player won against an SDK (who somehow placed 2nd in the end, but was eliminated by the DDK), then faced me in the final round after that, and lost, but they placed 3rd.

I’ll look for the link to the one I recall.

Edit : Here it is.

(SylTi was ranked 14k at the time we played, but played in the final with me, and should have been 2nd rather than 4th if ranking the standings purely based on double-elimination)


So it seems pretty clear that the prime suspect is that MacMahon type scoring is wrongly being applied to site DE tournaments, which is a double problem since firstly it shouldn’t be at all anyway and secondly ogs MacMahon scoring is also somewhat…err … shall we say unorthodox.

1 Like

Seems like this is a fairly common and wide spread issue then^ even more egregious to knock someone rightfully at 2nd to 4th.

Meanwhile, we can call it a “noob tax” for fun.


Interesting; another “automatic” tournament.

The configurations for automatic tournaments are stored in a database, and used to generate tournaments on a schedule. It sounds as if the stored configuration for “Live 9x9 D.E.” is misconfigured to have McMahon bars. I believe the configurations have all been in there a long time; maybe configuration validation wasn’t as good when these were created. I think only @anoek has access to this database to look into or fix these configurations.

If anyone has seen a similar problem with human-run (non-automatic) tournaments, please share a link. If the problem occurs with those, we’d want to check validation for “create tournament” and “edit tournament”.

I don’t have time right now myself, but it might be useful for someone to try to create a misconfigured tournament at to try to reproduce. IMO, the most likely way to trigger the bug would be: create a McMahon tournament, then edit it after creation (but before it starts) to make it double-elimination instead; it’s possible the McMahon bars would get left behind (bug), corrupting the initial points when the tournament starts.


I believe, if this happened, you could observe the bug as soon as the tournament started by using the tournament API that @Feijoa shared above. That’s because the points for McMahon bars are assigned as soon as the tournament starts (not at the end).

For example, this D.E. tournament is still in the first round, but you can look at the points via the API and see that they line up with wins/byes/ties (no strange McMahon points):

The same API exists on — if someone is able to run the experiment to create a tournament at, then they can check the API at after the tournament starts. I don’t think they’d need to play through any games.


I wrote up a bug here to track the fix for automatic site-wide tournaments: Automatic live 9x9 double-elimination tournaments have McMahon bars (!?) · Issue #2686 · online-go/ · GitHub


Glad to see the response taken seriously and all by members of the crew and public. Would have never even known to do this type of digging into the issue.


I tracked down the cause/timing of the bug.

  • The automatic tournament configurations have always had McMahon bars saved in settings, but they used to be ignored.
  • There was a change in January 2022 to evaluate McMahon bars when the tournament started; previously, they were evaluated as each player joined the tournament. This change inadvertently had the side effect of “activating” the latent McMahon bars in automatic tournament configurations.
  • Since then, the four varieties of automatic blitz/live tournaments have effectively had McMahon bars in effect. (The simultaneous round robins weren’t affected; and the simultaneous McMahons are supposed to have bars anyway.)

Hopefully there’ll be a fix before too long.


The next day

Love ya @dexonsmith !


Probably a big ask, but will previous tournaments be re analyzed and fixed with this upcoming patch implementation?

No, once the fix is in, future tournaments will be correct, but nothing retroactive.


FYI, future tournaments shouldn’t have this problem. and still had the negative points. and look fixed though.