Issues feed for user is broken

For what its worth I see the following behavior:

Logged in users only can access their own feed (uncached)

When logged in, I always get the content of my feed - regardless of whether I use my own uid or another on. E.g. https://drupal.org/project/issues/user/1/feed is the same as https://drupal.org/project/issues/user/63999/feed. Also I get the following cache-headers:

Via:1.1 varnish
X-Cache:MISS
X-Cache-Svr:www6.drupal.org
X-Powered-By:PHP/5.3.28
X-Varnish:928311661

Anonymous users get a cached response

When not logged in, I get a cached response, where the uid in the URL does not necessarily match the feed content. I.e. Accessing https://drupal.org/project/issues/user/63999/feed delivers the feed of any random user with some different combinations of cache-headers:

X-Cache:HIT
X-Cache-Hits:2
X-Cache-Svr:www6.drupal.org
X-Drupal-Cache:MISS
X-Varnish:928342653 928216305

X-Cache:MISS
X-Cache-Svr:www1.drupal.org
X-Drupal-Cache:MISS
X-Varnish:947377661

I think it is necessary to investigate the following things:

1. How does the uid-parameter in the URL work (for anonymous users) and why it is ignored when users are logged in?
2. Where does the content come from when rendering the feed for users which are not logged in? Is there another layer of cache involvide beside Varnish and the built-in page cache?

I'm having the same issue and I've been doing some further tests which add to the other findings in this issue as following (all with anonymous access):

• Using any web browser and going to https://drupal.org/project/issues/user/# always show the correct result
• Grabbing https://drupal.org/project/issues/user/#/feed instead delivers the wrong result in most cases and the chance are that caching mistakes are the source of that issue

What's interesting though, when e.g. grabbing https://drupal.org/project/issues/user/168924/feed I do get this result:

<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xml:base="https://drupal.org/project/issues/user/227729?text=&amp;projects=&amp;st
atus=Open&amp;priorities=All&amp;categories=All" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Issues for cbaldwin</title>
    <link>https://drupal.org/project/issues/user/227729?text=&amp;projects=&amp;status=Open&amp;priorities=All&amp;categories=All</link>
    <description></description>
    <language>en</language>
          </channel>
</rss>

Not only does the title (Issues for cbaldwin) indicate, that something is going wrong, also the rss element is just showing a different URL (https://drupal.org/project/issues/user/227729), i.e. user ID 227729 instead of the requested user ID 168924.

I have also confirmed this behaviour with a couple of development and staging servers at drupal.org and they all show exactly the same behaviour.

Then I looked into https://drupal.org/project/project and https://drupal.org/project/project_issue as I believe that those two are driving the delivery of those URLs. The project/issues/user/% and project/issues/user/%/feed are both defined in the same view and I can't tell what should be the difference between the two. However, these are just the view definitions in the modules, which doesn't tell if the configuration on the installed instances have been modified.

Looking at all of this it really looks as if caching and Varnish is doing something with those requests here and I can't get any deeper from here at this point - hoping that somebody rom the infrastructure team would kindly have a look.

Investigating on a staging server it turns out that requests to project/issues/user/%/feed from anonymous users never get through to drupal, they certainly get delivered by Varnish and for some reason that I can't investigate, there seems to be one cached page for all users, i.e. the first one requesting the feed makes it into Varnish and all subsequent requests get that page delivered ignoring their user id.

Edit: I tried to purge the pages from Varnish using drush, but the staging server has no access to the Varnish console as the connection is refused.

Looked at this a bit to see if it was Varnish, but it doesn't appear that it is. I'd imagine its a more internal cache. I fetched a variety of feeds with different user-ids as anonymous. There was a clear trend of the "next" user-id I tried being likely to return the feed for the "previous" uid I had fetched. An example fetch showing why I don't think this is varnish:

uid = 169454 (frank.melendez@ge.com)

Fetched: https://drupal.org/project/issues/user/169454/feed
Returned:
<?xml version="1.0" encoding="utf-8" ?>

Issues for krabbe

Obviously not correct. The cache headers:
Age:0
Cache-Control:public, max-age=0
Connection:keep-alive
Content-Language:en
Content-Length:44377
Content-Type:application/rss+xml; charset=utf-8
Date:Wed, 14 May 2014 16:29:29 GMT
Etag:"1400084969-0"
Expires:Sun, 19 Nov 1978 05:00:00 GMT
Front-End-Https:on
Last-Modified:Wed, 14 May 2014 16:29:29 +0000
Server:nginx/1.6.0
Vary:Cookie,Accept-Encoding
Via:1.1 varnish
X-Cache:MISS
X-Cache-Svr:www1.drupal.org
X-Drupal-Cache:MISS
X-Powered-By:PHP/5.3.28
X-Varnish:305517133

X-Cache is MISS, X-Varnish is only showing this thread id and not the populating ID and X-Drupal-Cache is MISS. This isn't related to varnish or the drupal page cache.

I'd guess this is a views level cache messing up, but that isn't really my area :).

Well, I'm a little lost here. In the devdrupal.org instance I've been testing with I replaced the index.php with a file that just prints "Hello" and then exits. When I then GET any of the feeds as anonymous user I do get the feed delivered - most times the wrong one as described by all commenters above.

This made me to conclude, that the request doesn't get down to Drupal but gets handled by an instance upstream. The only instance I was able to think of was Varnish, but maybe there's something else involved?

I think that needs some input from the infrastructure team though.

Having the same issue - visiting https://drupal.org/project/issues/user/271491/feed as logged in user everything works fine, when I log out though I'm getting someone else's feed, Issues for Jose Reyero, with <link> element pointing to https://drupal.org/project/issues/user/4299

Response headers:

Age	0
Cache-Control	public, max-age=0
Connection	keep-alive
Content-Language	en
Content-Type	application/rss+xml; charset=utf-8
Date	Tue, 03 Jun 2014 12:28:11 GMT
Etag	"1401797585-1"
Expires	Sun, 19 Nov 1978 05:00:00 GMT
Front-End-Https	on
Last-Modified	Tue, 03 Jun 2014 12:13:05 +0000
Server	nginx/1.6.0
Transfer-Encoding	chunked
Vary	Cookie,Accept-Encoding
Via	1.1 varnish
X-Cache	MISS
X-Cache-Svr	www6.drupal.org
X-Drupal-Cache	HIT
X-Varnish	1652740134

seem to suggest it's not Varnish, but rather Drupal cache.

If it were Drupal cache, then the HTTP request should be getting to index.php in the Drupal root directory, which isn't the case. That's why I came to the conclusion it must be something before the request gets to Drupal.

"Well, I'm a little lost here. In the devdrupal.org instance I've been testing with I replaced the index.php with a file that just prints "Hello" and then exits. When I then GET any of the feeds as anonymous user I do get the feed delivered - most times the wrong one as described by all commenters above."

After you edited index.php did you test with a new feed you hadn't tested with before or reload on old one? The old ones will still have been in the varnish cache.

Levels of caching are difficult to test correctly. When I was testing this I ensured that each level I was testing was cleared on the first load of each and used differentiating paramaters to narrow down where it was wrong. I was able to fetch the wrong feed for a UID with an entirely clear varnish and a page cache that said MISS.

"I think that needs some input from the infrastructure team though."

Nothing here makes me think this is Varnish atm.

I tried many times and it felt as if every 15 minutes the cache got rest and I got the correct feed for any of the tested UIDs. From that point on, I then tried different UIDs and what every I tried I kept getting the feed of the first UID.

So, which ever cache is responsible, when it gets cleared, Drupal produces the feed for the UID in the first request after clearing the cache and from that point on, Drupal doesn't seem to be involved anymore until the cache gets cleared again.

Doesn't that clearly mean, that Drupal is not guilty and that some other instance of cache somewhere upstream is responding to a feed request with the wrong content? If that upstream instance is not Varnish, what else could it be?

Below is a direct fetch on web1 of user 227730's feed. It returns user 264773's feed. This was directly against apache, bypassing varnish entirely. It is not varnish.

[root@www1 ~]# curl https://drupal.org:443/project/issues/user/227730/feed | grep user
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xml:base="https://drupal.org/project/issues/user/264773?text=&amp;projects=&amp;status=Open&amp;priorities=All&amp;categories=All" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <link>https://drupal.org/project/issues/user/264773?text=&amp;projects=&amp;status=Open&amp;priorities=All&amp;categories=All</link>
100  9349    0  9349    0     0  83858      0 --:--:-- --:--:-- --:--:--  194k

How do you know?

Any comment on my questions I raised?

I know its not varnish because I hit a port that apache is running on locally and not varnish. From there apache handles the request and passes it to php-fpm, from there Drupal handles the request. So, since it returned the wrong user feed, this is definitely a cache inside Drupal caching the incorrect content.

I don't know exactly what would cause that inside of Drupal, I'm more of a sysadmin than a developer. However, I'd guess that something is caching globally inside drupal, either the page cache or the views cache and is not picking up that for a logged in user the feed is always going to look like his/her feed.

Well, what I'm saying is that the request did never get to Drupal because it would have to be calling index.php as the first thing ever. If it doesn't get there, it doesn't get to Drupal.

This is reproducible on dev sites, http://drupal.org/node/1018084.

The project_issue_user_issues_searchapi View's feed_1 display currently has time-based Views caching. Switching to search_api_views_cache does not seem to help. Turning off caching for the View does fix this. There could be a root cause in SearchAPI, or Views itself; or maybe there is a misconfiguration in our View.

However, maybe we can just work around the problem and turn off caching for this display. It is only a 5 min cache, and feed readers hopefully won't have cookies and will hit Varnish/CDN if they throw lots of requests within 5 minutes.

Ya, I'd guess that would be fine. Varnish can cover for a surge and I cannot imagine this cache is a very high hitrate.

Can the views cache be selectively turned off for logged in users?

Can the views cache be selectively turned off for logged in users?

Not sure how easily - we would need a View cache backend, as in a subclass of views_plugin_cache, that does that and works well with SearchAPI Views. Or alter the cache with a bit of custom code.

Doesn't matter for feeds anyway, feed readers should not be authenticated.

I had this sitting in a dev site from testing. Ready to deploy now.

Now deployed.

Thanks a lot, this is now working like a charm.