Issue queues containing corrupt issues?

It's happening in gmap as well.. Only two rows though. http://drupal.org/project/issues/gmap

No idea. Never seen anything like this before on any of the project* sites I've ever setup elsewhere. I'm so out of the loop on the d.o DB infrastructure side of things, I wouldn't even know where to begin trying to track this down. My first inclination would be to turn on the devel module for a little while, see the query log on those pages, run the queries manually, and see what that turns up.

@killes and/or @nnewton: Any ideas on if anything y'all have been tweaking with recently could have caused something like this?

Strange, I can see one missing title in the gmap queue, but none in the cck queue.

the two missing in gmap are #312077 and #312801

I can execute the node_load query for these just fine, but some error leads them to not be fully loadable, the node pages give me a 404.

What is strange is that both nodes belong to user Cactii http://drupal.org/user/346936

the missing cck issues also belong to Cactii..
http://drupal.org/project/issues?projects=48429&participated=Cactii

an also all of his comments are invisible
http://drupal.org/user/346936/track

Yeah, this is very strange. The relevant rows in the DB tables are all there for the few issues I looked at, but the pages are giving 404s and node_load() is indeed returning false. Very bizarre.

So, I just ran a little PHP code from the shell on one of the d.o servers (www1 in case that matters).

I cut and pasted the query from node_load() in d.o's copy of node.module:

$node = node_load(307284);
print var_export($node, TRUE) . "\n";
$cond = 'n.nid = %d';
$arguments[] = 307284;
$node = db_fetch_object(db_query_slave('SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM {node} n INNER JOIN {users} u ON u.uid = n.uid INNER JOIN {node_revisions} r ON r.vid = n.vid WHERE '. $cond, $arguments));
print var_export($node, TRUE) . "\n";

This results in the following output:

false
false

However, if I change that db_query_slave() into a plain old db_query(), all is well:

$node = node_load(307284);
print var_export($node, TRUE) . "\n";
$cond = 'n.nid = %d';
$arguments[] = 307284;
$node = db_fetch_object(db_query('SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM {node} n INNER JOIN {users} u ON u.uid = n.uid INNER JOIN {node_revisions} r ON r.vid = n.vid WHERE '. $cond, $arguments));
print var_export($node, TRUE) . "\n";

This gives:

false
stdClass::__set_state(array(
   'nid' => '307284',
   'vid' => '354920',
   'type' => 'project_issue',
   'status' => '1',
   'created' => '1221184573',
   'changed' => '1221184573',
   'comment' => '2',
   'promote' => '0',
   'sticky' => '0',
   'revision_timestamp' => '1221184573',
   'title' => 'Missing DB Column',
...

So, it does seem to be a problem with the replicated DB configuration, not an obscure bug in project_issue...

@killes: I'm near the limit of my ability to debug this any further -- perhaps we should get nnewton on the case?

Thanks,
-Derek

Hi All,

I'm looking into this. The slave fell out of sync and was not caught by the checksum script. It is fixed now and I'll let you guys know the cause when I find it. Thanks for the report.

Seems fixed now.