Too-aggressive caching? I now see:
https://api.chess.com/pub/player/jimbo2019/clubs
{"clubs":[]}
Bug in clubs end point
Sort:
Jan 1, 2019
0
#2
Jan 1, 2019
0
#3
Thanks Giles. As you say this problem has disappeared,
I thought it was very odd that this issue came on the next process line as the non alpha char bug. @jd
, I also reported.
Although the line after these two processed without incident.
Jan 1, 2019
0
#4
I wouldn't be sure it's disappeared. I suspect a caching problem (or limitation): it's in my experience far safer to cache positive results. (Even an empty list of clubs is a positive result.) Caching negative results (who?) is easy to display inconsistencies: if someone's profile can be fetched but not their club memberships, it's a PITA.
I don't know what control over caching (and updates of the caches) is possible but when there is a cache "miss" I personally would like no or very short (60s-300s) caching before that member's results (if they are a member ... might not be of course) are updated in the cache.
For DNS, it turns out that the documentation/specification for how long results may be cached is well and good, but when a result doesn't exist (especially a SOA record for a new domain) caching much at all led to pain for one DNS implementor. I'm extrapolating, but it's worth thinking about how cache misses are handled I believe.
This user exists. Web page is OK. API link returns correct data.
https://api.chess.com/pub/player/jimbo2019
Clubs link returns error message
https://api.chess.com/pub/player/jimbo2019/clubs
{"message":"User \"jimbo2019\" not found.","code":0}