Inconsistency of data in Team Match endpoint

There is an inconsistency in the API endpoint URL pattern: https://api.chess.com/pub/match/{ID} 

This table shows how fair play closures are handled by web page and API in team matches.

Shouldn't the API reflect the web page?

No further team score adjustment is made for accounts closed for fair play violation after a match has finished - is that what you're querying because it's not entirely clear to me?

I think it's the in-progress per-board inconsistency (the red text).

It's slightly tricky if I'm understanding correctly:

1. The aggregate scores are OK per @Tricky_Dicky

2. The per-board result is not adjusted, however I don't think it should be: going from a team match list of boards to individual games shows unadjusted results

3. @Tricky_Dicky, these are the parts of the team match endpoint I'd be looking at and expect to be adjusted:

  ...
                  "played_as_white": "string", //result {win, lose, resign, etc.} of player when played as white (if game's finished)
                    "played_as_black": "string"  //result {win, lose, resign, etc.} of player when played as black (if game's finished)
...

Perhaps "fair_play_loss" should be added to the game results codes. The big red zeros on the match listings would be consistent with that.

My big problem here is the web page and the API give different answers for the board results. Isn't the principle here that the API should return the web page data?

The trouble is there are three answers.

1. What is shown in the match, e.g. board #19 in this debacle of a match: https://www.chess.com/club/matches/oracle/876452/games There @PETROSS55 is shown as winning both games
2. If you go to each game, https://www.chess.com/daily/game/189723430 and https://www.chess.com/daily/game/189723434 you'll see @PETROSS55 was checkmated in both games
3. If you use api.chess.com and look at the match data, it shows @PETROSS55 winning one game and being checkmated in the other: https://api.chess.com/pub/match/876452

"username":"petros55","stats":"https://api.chess.com/pub/player/petros55/stats","status":"basic","played_as_white":"checkmated","played_as_black":"win","board":"https://api.chess.com/pub/match/876452/19"}

I think the results shown in #1 are correct, ditto #2 is correct, and #3 is not correct as the "played_as_white" result should be "win". The results in the match data from api.chess.com for the opponent (closed:fair_play_violations) are similarly mis-matched to what the website shows.

Basically, you're right(*), and I agree you're right, and think there's  a bug here. Perhaps the concrete example now I've chased one down will help someone figure it out.

(*) "Right" being that the board data give the actual game results as looking at an individual game on the website does, and the match "played_as_white" and "played_as_black" match what is shown in the adjusted match display. If you don't agree that's "right" then there's more discussion needed.

Yes That's exactly my point. The API is showing the board results but the match Web page shows an adjusted result due to FPB. You have also highlighted another issue as the individual board web page is in line with the API.

Maybe the answer here is another code for game result as you suggested. Loss by FPB.

Is there a need to retain the actual board result in some form, somewhere?

I think the individual games on the website and via board number for api.chess.com should show the natural result; checkmate, resigned, won on time, whatever. That's the true record of the game that was played.

I suggest the played_as_white and played_as_black be made consistent with the match display, and optionally that a new code for a fair play adjustment be added.

I think a new code is optional; it might be nice but if "won on time" remains then there's really no way to tell if the result of that game was adjusted. You can try comparing its end_time with the opponent's last_online time but sometimes staff to "something" that updates last_online time. Thus the confusion between a game a cheat timed out on before an account closure versus a game lost on time after the closure.

An account closed time would be nice.

"Really no way" is probably not quite right. "won on time" is not an adjusted result. What can't be known easily was whether the game timed out before or after the account closure. Not 100% accurately.

Now I should stop looking at a computer screen (headache) and I curse the Australian politicians who made it necessary to have a prescription from a doctor for a headache tablet, and of course I have run out ...

Thanks Giles. And hope you are OK.

Better today thanks. I get cranky that a pharmacist can no longer sell codeine "over the counter" without a prescription where I live yet highly a highly poisonous (and to me useless) drug like paracetamol (acetaminophen)  is available in any supermarket no questions asked. 

Democracies sure turn up some odd politicians and thereby odd laws.

<end topic drift/>

I've been waiting to see if a member of the development team would post an opinion or explanation here, because that might have given some background on why things are being done the way they are.

I thought one of the principles underlying the rollout of API on this site was that endpoints should match web page content as closely as possible? Clearly not the case for the team-match endpoint!

* Since Giles quoted a TMCL team match above, may I reassure anyone taking part in that league that the way I calculate adjusted (for accounts closed for fair play violation) results is unaffected by the inconsistency between web-page & API endpoint data.

That it was a TMCL match was, ah, because the horror of that match is in my brain.

I knew it had closures for fair play violations during registration, while in progress and I am pretty sure another account went after the match was completed. So it's a "good" example for puzzling out website vs API differences and doesn't have a lot of boards either.

As one of the SAs for one of the teams, I'm not very happy that my team had so many fair play closures.

* I too have a script that calculates the adjustments as per TMCL's 2018 rules, and it agreed in all cases with Stephen's results. That my horror example happened to involve TMCL was happenstance, and may I never be part of a match with that many fair play closures ever again!

It would still be interesting to hear from staff; if this is on the "we're thinking about it" pile even knowing that would be nice and possibly useful.

It has spurred me to get my hands dirty and write code that will do adjustments correctly for all circumstances. One other minor problem with this API data is the classifications of Closed:

There are only two as far as I can see. Closed:Fair play violation and Closed:.

So no distinction between Abuse and self closed/ inactive.

Suspect all coding staff have been busy with the new navigation.

I'm pretty sure I've seen a profile status of "closed:abuse", @TrickyDicky. The last one I recall was reversed after an appeal by the user, but I'll see if I can find one.

Either I misremember or the feature has been lost:

https://www.chess.com/member/skymarshal

versus

https://api.chess.com/pub/player/skymarshal

Note: @skymarshal (one "ell") is the account; @skymarshall (two "ells") is a different account.

You may be correct Giles, but not in Team Match end point. I've just checked a player profile of an abuse closure and got this:

"status":"closed"

Just checked @skymarshal and got same as above.