When I load an answer via the Stack Exchange API, the
answer.tags field disappears if the filter also includes the
Normal query, filter
!9YdnSLHTQ: (run it)
With a filter including "share_link"
!9YdnSLHPy: (run it)
(The answer in this example is chosen totally at random and has no special significance.)
The filters can be plugged into the filter debugger to verify that both include the
answer.tags field. I have verified that there is no difference between the filters except that the second filter also requests a
This is not specific to the
/answers endpoint. Other API endpoints that return answer objects seem to have the same problem.
When I run the second query, the first time it will contain an empty array for the
tags. For subsequent requests (using either query), no
tags field is present. When I run the first query again, the
tags field will still be missing for a while, but re-appear at some point (on the order of minutes).
So I think we can blame caching?
Importantly, this makes API requests stateful – previous requests affect the results of subsequent requests for a short while.
This caching could make the above behaviour difficult to reproduce. But since I could reproduce it multiple times consistently, I'm confident the problem is real.
- Filter doesn't consistently return comment bodies (2014, no answer)
reposted on MSE (2017, no answer)
- Creating an API filter with comment.body_markdown but without comment.body (2015, no answer)
- API doesn't return 'body_markdown' on comment endpoint (2015, no answer)
- Where are the rest of my API results? (2016, no answer)
- API cache behavior can be exploited to hide posts from API clients (2018, fixed) – another case of wonky caching. Was fixed by not caching empty responses. My case might still be due to the same problem if
answer.tagsis cached independently, as the absence of
answer.tagserases this field from subsequent responses.