I noticed that sometimes when a new comment is added, the "Last updated" date on my tracker does not get changed. So I am seeing things like the "new" mark appearing on my tracker for a node that is way down on my list. When I go to the node, I see that a new comment was in fact added, but the "last updated" date on the tracker is still old and does not reflect that.

This seems to happen only intermittently.

Here is an example... right at this moment, my tracker page (http://drupal.org/user/124982/track) lists #330983: Rename user module tables to singular as last updated "9 hours 23 min ago", but if you find that node on the main tracker page (http://drupal.org/tracker) it is listed as last updated "28 min 14 sec ago". The latter is the correct info.

Comments

tstoeckler’s picture

Just want to confirm this weird behaviour of tracker. Exactly as described above.

tsvenson’s picture

I too can confirm that the same thing happens to me.

greggles’s picture

I too have seen this (we probably don't need more confirmation at this point...).

Note that drupal.org uses http://drupal.org/project/tracker2 so this is a bug in that module specifically.

David Strauss’s picture

Subscribing (and attempting to verify).

David Strauss’s picture

I'm wondering if load issues were the cause of this. We're using the exact same indexing code we used before.

Is there a reliable way to reproduce this?

David Strauss’s picture

Another test comment.

tsvenson’s picture

It seems to me it get stuck in either the last update before the upgrade or the first update/reply after the upgrade. It does update for the first reply/update to new posts/issues, but then no more. At least that is how it seems for my tracker.

David Strauss’s picture

Let's try a new comment with new Tracker 2 code.

tsvenson’s picture

Quick amendment, for new nodes, with our without existing comments, added to my tracker it only update the time one time.

Also, I tried to edit my previous reply and got "You must enter a project to navigate to." when I tried to save it. Should it be so or is that another bug?

David Strauss’s picture

Assigned: Unassigned » David Strauss

I've patched the live code to forward-port the old db_query() method of updating Tracker 2 data. Using drupal_write_record() appeared to fail whenever we were updating Tracker 2 records when someone posted a comment to a node they had already commented on.

tsvenson’s picture

Assigned: David Strauss » Unassigned

Oki, my tracker got properly updated with the new code now.

David Strauss’s picture

Assigned: Unassigned » David Strauss
Status: Active » Fixed

This has been deployed and fixed in the latest tracker release, though this probably indicates a bug in drupal_write_record().

David_Rothstein’s picture

Project: Drupal.org infrastructure » Tracker 2
Version: » 6.x-1.x-dev
Component: Other » Code

Thanks for fixing this!

I looked into where the bug is and I think it was in the previous Tracker 2 code, not drupal_write_record(). The previous code looked like this:

$insert->uid = $uid;
if ($exists) {
  drupal_write_record('tracker2_user', $insert, 'nid');
}
else {
  drupal_write_record('tracker2_user', $insert);
}

The intention of the first drupal_write_record() is to run something like UPDATE {tracker2_user} SET changed = %d, published = %d WHERE nid = %d but because $insert->uid is set, that gets included in the query too, so it tries to update all rows for the node to have the same uid, which of course is wrong (and prevented by the schema)...

So there's probably a way to fix this that continues to use drupal_write_record() in most places. I'll roll a patch if you want, although given that it's working now, maybe it's best to leave well enough alone :)

David Strauss’s picture

Thanks, David. I'm not inclined to move this back to drupal_write_record(). The abstraction it provides is not amazing for Tracker 2 (we're not dynamically changing the queries), and it will only slow down, having to look up schema data to generate the queries.

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org upgrade

Automatically closed -- issue fixed for 2 weeks with no activity.