The api.drupal.org site again seems to be failing to update - changes I made to the developer docs last night are not reflected, and function _menu_find_router_path() which was added to the codebase a few days ago does not appear.

Comments

pwolanin’s picture

pwolanin commented

On IRC, killes said he manually ran the cron job ~15 minutes ago, but the changes still don't seem to be reflected

drumm’s picture

drumm
he/him
Location NY, US
commented

I'll look into this. It can take more than 15 minutes since a shell script needs to run on cron and drupal's cron needs to run.

drumm’s picture

drumm
he/him
Location NY, US
commented
Title: API site not updating- cron problem? » Some functions can be missing
Project: Drupal.org infrastructure » API
Version: » 5.x-1.x-dev
Component: Operating system » Code

This is now an API module bug. http://api.drupal.org/api/file/includes/menu.inc/6/source has the function, but has not parsed it as a function.

drumm’s picture

drumm
he/him
Location NY, US
commented
Title: Some functions can be missing » Remove leading space from _menu_find_router_path() definition
Project: API » Drupal core
Version: 5.x-1.x-dev » 6.x-dev
Component: Code » menu system
Category: bug » task
Priority: Critical » Minor

The API module assumes that function definitions have no leading spaces. This is a code style issue since in Drupal source code, they should not.

pwolanin’s picture

pwolanin commented

Hmmm, well this hook definition also still gives "Page not found"

http://api.drupal.org/api/function/hook_menu_alter/6

drumm’s picture

drumm
he/him
Location NY, US
commented

Works when logged in, so this is a squid thing.

pwolanin’s picture

pwolanin commented

ok, well, I'll check again later, since I can't log in to API.

Issue with patch for the extra space in the function def: http://drupal.org/node/172604

emsearcy’s picture

emsearcy commented
Status: Active » Closed (duplicate)

Note, the last few emails from Narayan and Neill went to the infrastructure mailing list only, not on this ticket.

Marking as duplicate of http://drupal.org/node/163972, but I'll post comments here too. In short, no, it's not Squid.

Reasoning: the HTTP headers prevent Squid from caching API pages. Viewing Squid's cache object list shows `affected' pages as having the same last-updated time as as the last-viewed time, and an expiration in 1970. This means that each page view is pulling from Apache, not the Squid cache. Furthermore, I have verified this by viewing the Apache logs: each pull of the page containing the stale data is being served by Apache.

Perhaps the caching is occurring at the memcache level? I don't know anything about Drupal internal caching, but I believe this is bypassed when logged in, right?

emsearcy’s picture

emsearcy commented

Ticket also reasonably a duplicate of http://drupal.org/node/164678 (the same problem was documented in many places). My comments are more germane to that ticket, so I'll be posting them there, not 163972.