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

C.C have changed the policy on how daily matches are handled when minimum boards not achieved.

https://api.chess.com/pub/match/{ID}

This has resulted in a change to the API endpoint.

Unannounced, undocumented and nothing in CHANGELOG

Extra fields added. Fields missing. Board numbers missing.

Published specification is now completly wrong for these circumstances.

Oh cr**!!!!

Indeed. My script just bombed, Worked for about 4 years. Can't be arsed to do anything currently.

This is what you get in this circumstance.

Not the issue I know but I think that match was set to start 9 hours earlier than the WL 960 schedule?

Explains why I can't open it in my browser - it's gone.

If the API isn't stable it's not reliable and therefore of limited use, so I hope this isn't a sign of other things to come?

Which fields do you notice are missing, Richard?

Oh you are saying the details of individual boards is completely missing? This sounds like a bug

Don't think it's a bug. Looks to me the endpoint has been revised, removing board numbers as the match has been auto cancelled by the revised C.C policy.

But it looks as though other fields have been changed and some have been moved.

'result' is new

'board' is missing from players (this is what stopped my code)

'end_time' isn't in the spec

'@id' isn't in the spec for the endpoint url

'initial_setup' isn't in the spec

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

Curiously the "result" for each team is shown as "lose", even for the team that reached the minimum.

That might be the simplest way of removing such matches from any analysis?

Also not to give points.

Yes I think checking 'lose' for both teams but then for leagues that award default wins for the team with enough registered players need to check roster numbers and compare to minimum boards setting.

Really pissed off that there was no warning and having to recode retrospectively.

It removes the option of allowing a defaulting team a respite period to recruit more as this bar comes down at expected match start time but that's a topic for other forums.

"..for leagues that award default wins for the team with enough registered players need to check roster numbers"

That affects me and as far as I can see the change actually improves things because it has the effect of 'freezing' both teams at the point the match is scheduled to start.

Had an awkward situation a little while ago in which one team in a TMCL league match failed to achieve min. players by the start but the extra 'one' joined about 15 minutes after. Usually I'd have carried out a scan of all matches soon after the start but something had distracted me and I had no way of knowing when the player had joined.

Well it seemed as if all was fine until the opponent posted a screenshot showing the team with the 'late joiner' was in default at the start and they demanded the match point. We decided to act on the screenshot evidence and award the point but I could have done without that.

From now on we should know exactly when a team has failed to meet the team size requirement.

Been thinking more about this and the implementation shows little logical thought (again)

This match https://www.chess.com/club/matches/1534049/games displays 'This Match Has Ended In A Draw' on web page.

Players per team shows 6

Team 1 has 6 registered, Team 2 = 32

Min boards was set at 25 for registration.

Team 1 failed, team 2 have exceeded requirement.

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

Match status 'finished'

Boards = 6

min_team_players = 25

team 1 'result' = 'lose'

team 2 'result' = 'lose' : What is the logical reason for this?

Due to how the registration phase ended, the web page should award the match to team 2 and the API team 2 'result' should be 'win'.

What have the staff said about this? Since the match was forfeited does it make much sense for the site to award the match point to one team or the other?

I think they're probably leaving that to us to decide.

I think the site is going to have to introduce a new category of match result (Unresolved/Undecided/Forfeited) or award the match one way or the other but what does it do when both teams fail to reach min. players?

I take the point Stephen but Web page says Draw, API says double loss. Makes no sense to me.

And Staff have said Zip. The whole thing has been rolled out without any warning or information.

I totally agree but I have a feeling that they've done only half the job and where neither team has a win, the software defaults to "Draw"?

This is turning into a complete F-up

For a defaulted match the board number is taken as the registered players from team 1 rather than the lower of the two on the web page. The API endpoint shows the lowest number.

https://www.chess.com/club/matches/1535379/games

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

Thank you for pointing this out.

I designed my script to handle empty results such as what is returned here: https://api.chess.com/pub/match/1535379/1 so for me nothing critical broke thankfully.

The issue for me is reporting overall match results as both teams would be given a "loss" in this case as you mention in comment #12. Hopefully this gets looked at.

It's difficult to imagine how any script won't need some re-coding due to this change. We've gone from having a match still shown as in 'registration', because specified player numbers haven't been met, to one that's now 'finished' and with results of 'lose' for both teams.

How could any of us have allowed for that in our original designs?

I've put in a fix in my main program and seems to be working.

Check 'finished' match for both teams 'lose' in the undocumented field 'result'

If true then 'match defaulted' else continue as previous.