Warning/interesting: profile "last_online" may be older than stats "last" value

Hi,

I'm writing a report to figure out:

a) Who in a team plays Chess960

b) Who of (a) hasn't signed up for a match

c) What the last date a player in (a) played a Chess960 game, as some try it and don't like it

d) ... and ratings plus W/L/D information of course!

I have this oddity:

@nomoneyhoney      2015       178W/41L/31D  last_online: 2017-12-26  last game: 2018-01-23

The output is:

Player, rating, W/L/D, last_online (from the player's profile) and the last 960 game (from stats).

If the date of the last game is a few days after last_online I wouldn't worry: conditional moves, timeouts, etc. Let's look into it.

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

{"avatar":"https://images.chesscomfiles.com/uploads/v1/user/19775150.1b79901c.200x200o.252b429ce6da.jpeg","player_id":19775150,"@id":"https://api.chess.com/pub/player/nomoneyhoney","name":"Gary Basanta","username":"nomoneyhoney","title":"FM","followers":635,"country":"https://api.chess.com/pub/country/CA","location":"Vancouver, British Columbia","last_online":1514254693,"joined":1416289221,"status":"premium"}

1514254693 is Tue Dec 26 02:18:13 2017 UTC. Matches my output, good.

https://api.chess.com/pub/player/nomoneyhoney/stats

{"chess_daily":{"last":{"rating":2107,"date":1506922623,"rd":132},"best":{"rating":2107,"date":1497835205,"game":"https://www.chess.com/daily/game/121937966"},"record":{"win":82,"loss":7,"draw":5,"time_per_move":36549,"timeout_percent":40}},"chess960_daily":{"last":{"rating":2015,"date":1516724409,"rd":77},"best":{"rating":2078,"date":1478254457,"game":"https://www.chess.com/daily/game/168462380"},"record":{"win":178,"loss":41,"draw":31,"time_per_move":36549,"timeout_percent":40}},"chess_rapid":{"last":{"rating":2007,"date":1497609919,"rd":141},"best":{"rating":2080,"date":1445576874,"game":"https://www.chess.com/live/game/1117461666"},"record":{"win":41,"loss":15,"draw":6}},"chess_bullet":{"last":{"rating":2402,"date":1508823356,"rd":27},"best":{"rating":2499,"date":1497611303,"game":"https://www.chess.com/live/game/2290885162"},"record":{"win":803,"loss":464,"draw":88}},"chess_blitz":{"last":{"rating":2425,"date":1508425414,"rd":49},"best":{"rating":2465,"date":1497862923,"game":"https://www.chess.com/live/game/1174895365"},"record":{"win":837,"loss":481,"draw":101}}}

1516724409 is Tue Jan 23 16:20:09 2018.

My code is reporting the data I'm getting as JSON from api.chess.com, but those two values look quite odd.

Now check the archives for @NoMoneyHoney (who appears to be on vacation) and the last 960 game he lost was a no vacation tourament game on 24 Jan 2018, which allowing for timezones fits the timestamps.

Summary: no bug here, but stats can correctly report games ending quite some time after someone has been logged in if vacation is involved. A new tournament round started, the player is on vacation and not online, didn't notice, loses game(s) and stats is updated with a newer date than the last time the player was online. Puzzle solved.

I am going to post this anyway (with a title without "bug" in it ) as this behaviour was counter-intuitive to me and may be to others.

 Looks like @NoMoneyHoney had a tournament he was part of come back to life, thus causing him to start - and lose - long after his most recent login date.

Yup. That's what I worked out. I don't know if the writeup will help anyone, but with the right search terms it might.

I think all data that was reported was correct; merely surprising. (Surprising to me at least.)

I think it's quite common for an abandoned account to have new games started from old tournaments coming back to life.  With accumulated vacation time, sometimes those games can hang around for a bit, especially for titled players who have free diamond and therefore lots of vacation time.

Right. No argument. But it surprised me; experience says what surprises me about new software often surprises other people(*) so I wrote it up. Maybe a waste of time, maybe not.

(*) Having been the lead support engineer for the introduction of two virtualisation products my experience is not typical. When I finally met the development team for one of them, some of their members were aghast when I told them the first thing I did with one of their new releases was toss the manual on the shelf and load the software.

Customers don't read the manuals.

In this case, the documentation for api.chess.com is pretty good, but it's also pretty limited: it says what you can get, but the interactions of the different parts and the effects of caching are still being worked out, partly because how long different endpoints' data should be cached is subject to change.

This behaviour isn't a caching effect, although initially I wondered if it was.

There is at least one bug report outstanding (the weekly/monthly/all_time breakdown of club memberships) that is totally broken. Caching will be involved in that problem; whether a workaround will be found or the split into weekly/monthly/all_time activity will be abandoned is I imagine not yet decided.

An unfortunate compromise would be to leave weekly and monthly empty and simply load all members into all_time, but I hope that doesn't happen. I would prefer a breaking change.

But whatever happens, when I want a date for activity I'm going to be using the per-user profile endpoint, as coding to use the club information is impossible now and why risk it later?