Changed match policy results in incorrect API end point https://api.chess.com/pub/match/{ID}

I hope they will fix that bug. It isn’t valid to call that match lost for both clubs if one has made the minimum.

Just realised somehow I am in a forum for software developers. 
I will be quiet now. 
😎😎😎😎😎😎😎😎😎

Not sure how that happened.

Lou, technically the site isn't doing that because on the match webpage, the result is shown as 'Drawn' I think? It's only in the data that very few people see that both results are 'lose'.

But it's difficult to know what other status the team results can be given without introducing a new one such as 'annulled' or 'void'. Clearly the site can't assign a 'win' or 'draw' to either team because that wouldn't reflect the outcome - the match has been cancelled/aborted.

Perhaps that's the proper solution? Treat such matches as if they've been aborted? Of course that would be very unsatisfactory for some of us because we need to see team player numbers to decide on which team failed to achieve the minimum.

Setting aside the immediate problem of needing to edit small parts of my code, I see this as a slight improvement because it gives a clean and emphatic solution to the problem of identifying teams that fail to reach minimum player numbers by a specified start time.

Not so good I imagine for those running match tournaments who like to allow a little leeway for teams that get into that situation?

Just confirmed what I feared: the script I made to compensate for the broken top player list is affected too. I really didn't want to fix that script today :/

FFS!. I think the endpoint has been changed to show 'draw' insteaqd of 'lose' for both teams.

How is it possible that these changes are implemented without any notification.

Is it now the same for tied matches and matches not started because criteria weren't met?

https://api.chess.com/pub/match/1586655

This is the match example above which now shows a different return.

https://api.chess.com/pub/match/1534049

I don’t they ever notify of changes. You just have to discover them.

Just checked a tied match.

https://api.chess.com/pub/match/1477109

This now shows exactly the same result as a match defaulted due to criteria. What a farce.

Where is the logical thinking about these implemenations?

You are certainly correct. https://www.chess.com/clubs/forum/view/changelog Hasn't changed in years.

Not exactly T_D, in the case of any match in default, due to insufficient players at the start, each team's data shows the following....

https://api.chess.com/pub/match/1590561

"score":0,"result":"draw"

So test for that combination and it's certain that it's a defaulted match, not a match that ended in a draw.

What I did was check if the match is not in registration status and if number of boards is less than settings.min_team_players. Stephen's test is simpler obviously

Thanks both, Appreciate the suggestions. When I found the change I went into a meltdown as it just broke my script. And then had to investigate to find out why. So frustrating that there was no advance notice.

I also saw that Ben has left C.C according to his profile header.

"I went into a meltdown as it just broke my script" - I know that feeling well 😡

I've spent years trying to create work-arounds for the many unannounced changes this site has implemented. Did you notice that a new key-value suddenly appeared in matches ("settings") some time ago...

"initial_setup":""

Not entirely sure why that's required if the value string is empty/null? Other keys like min/max ratings are optional, so why not that?

Locating and fixing that took an hour of my life that I'll never get back.

Do you have declare all the keys that you might get in the response? In most languages you can simply ignore unknown keys

Only thing I can think of for "initial_setup":"" is if it's a themed daily team match and that would contain the FEN? Rare circumstance.

"Do you have declare all the keys that you might get in the response?" - no because ratings limits are optional and don't appear unless there's a deliberate setting. Is that what you meant?

"Only thing I can think of for "initial_setup":"" is if it's a themed daily team match" - yes, that's what I assumed too but why include it when it's not in use?

I misunderstood above - no problem in Python having any number of keys but I use a specimen dictionary of settings to compare with the actual settings in the match, to make sure all are correct.

I suddenly started getting one indication after another that match settings had some error in them but it took a while to work out that was because a new key had appeared that wasn't there previously.

Not that easy to work out which keys are optional (only present if set by the challenge creator) and which mandatory (always present).

Also useful for 960.

I don't think that's the case. C960 setup's don't generally get published during registration. The FEN is only revealed when the match starts. Maybe would be if it was a predetermined C960. Not sure.

I'll try that when I have the occasion.