API doesn't return "answer.tags" field if I also asked for "answer.share_link"

Question

When I load an answer via the Stack Exchange API, the answer.tags field disappears if the filter also includes the answer.share_link field.

Normal query, filter !9YdnSLHTQ: (run it)

/2.2/answers/356178?order=desc&sort=activity&site=softwareengineering&filter=!9YdnSLHTQ

With a filter including "share_link" !9YdnSLHPy: (run it)

/2.2/answers/356178?order=desc&sort=activity&site=softwareengineering&filter=!9YdnSLHPy

(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 share_link.

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.

Possibly related:

• 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 or answer.tags is cached independently, as the absence of answer.tags erases this field from subsequent responses.