99519 - Invalid timestamp in cc, no e-mail

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P1)

Description

[Marcel Telka]

When you add yourself only as cc to any bug, this activity is logged with bad
timestamp (previous last activity timestamp is used intead of current time) and
e-mail to particular persons is not sent.

Comment 1

[Marcel Telka]

Added cc with Additional Comment (testing this bug).

Comment 2

[Marcel Telka]

Removed myself from cc.

Comment 3

[Marcel Telka]

This bugzilla installation seems ok. But my installation have this bug... :-(

Comment 4

[Matthew Tuck [:CodeMachine]]

Have you made any changes to the code?

Comment 5

[Marcel Telka]

No.

I have configured my bugzilla installation only via changes in localconfig file
and through web interface.

Note: This bug was present in my bugzilla-2.12 too.

Comment 6

[Dave Miller [:justdave]]

What OS do you have it running on?

Comment 7

[Marcel Telka]

RedHat Linux 7.0 with some packages upgraded (from RHL 7.1).

Comment 8

[Matthew Tuck [:CodeMachine]]

Moving to future until we can reproduce this.

Comment 9

[Marcel Telka]

We have now our bugzilla available from inet.
Please see https://bugzilla.etc.sk/show_bug.cgi?id=20
We are using mysql-3.23.32-1.7 installed from rpm package.

Comment 10

[Dave Miller [:justdave]]

*** Bug 100905 has been marked as a duplicate of this bug. ***

Comment 11

[Dave Miller [:justdave]]

OK, we have two more sites that can reproduce this now, both under control of
core developers.  Ought to be able to track it down now...

Comment 12

[Dave Miller [:justdave]]

many thanks to Brad Baetz for tracking this down...  turns out to be a
difference in the way MySQL 3.23 handles timestamp fields compared to 3.22.

In 3.22 if you so much as touch a row with an UPDATE statement, it updates the
timestamp field.  In 3.23, the timestamp field is not updated unless the data
actually changes.  (So setting a row to the values it already had won't update
it).  CCs and dependencies thus would both have this same problem.

Comment 13

[Dave Miller [:justdave]]

Attachment: Always update delta_ts if anything gets logged to the activity table

Comment 14

[Bradley Baetz (:bbaetz)]

s/row/column in the row with a mediumtext (At least)/

Stranger and stranger...

Comment 15

[Dave Miller [:justdave]]

This is going to be a blocker for the 2.16 release

Comment 16

[Dave Miller [:justdave]]

Comment on attachment 54432 [details] [diff] [review]
Always update delta_ts if anything gets logged to the activity table

$bug_changed is being set inside the wrong routine, should be in the main
logactivityentry routine and not in logdependencyactivity.

Comment 17

[Dave Miller [:justdave]]

Attachment: Patch v2

Comment 18

[Bradley Baetz (:bbaetz)]

Comment on attachment 56329 [details] [diff] [review]
Patch v2

r=bbaetz

I tested this on mysql 3.23; someone should probably check on 3.22

Comment 19

[Jacob Steenhagen]

Comment on attachment 56329 [details] [diff] [review]
Patch v2

>Index: process_bug.cgi
...
>         SendSQL("INSERT INTO bugs_activity " .
>                 "(bug_id,who,bug_when,fieldid,removed,added) VALUES " .
>                 "($i,$whoid,$timestamp,$fieldid,$removestr,$addstr)");
>+        $bug_changed = 1;
...
>+    if ($bug_changed) {
>+        SendSQL("UPDATE bugs SET delta_ts = NULL WHERE bug_id = $id");
>+    }


This still has problems, when LogActivityEntry() is called, it still has the old
value for $timestamp.  I suspect this is caused by the code at:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/process_bug.cgi&rev=1.103&mark=1128-1134#1124

But I'm not sure what the solution is (my brain doesn't work quite right at
2:30 AM :)

Comment 20

[Dave Miller [:justdave]]

That's on purpose so that every change logged to the bug as part of the same
action gets stamped with the same time.  Since the final statement there is
setting the timestamp on the bug itself (not the activity log) at the current
time (which is probably a half a second or so after the timestamp used in the
activity log) this is not a problem, since it's STILL after the last lastdiffed
time, which is the important thing here.

Comment 21

[Bradley Baetz (:bbaetz)]

No, this is correct behaviour. The second time may be too late (by some
seconds); that doesn't matter, because its later, not earlier, so midairs still
work.

Comment 22

[Dave Miller [:justdave]]

Attachment: Patch v3

Comment 23

[Dave Miller [:justdave]]

Turns out that besides the timestamp not updating when nothing changed, there
were fundamental flaws in the way process_bug was generating the timestamp being
used in the activity log.  It now always uses NOW() as the timestamp, whether or
not it's submitting anything to the bug to be changed (because it almost always
does - and usually just sets those to the same values, which means delta_ts
won't auto-update under MySQL 3.23).

Comment 24

[Dave Miller [:justdave]]

Attachment: Patch v4

new attachment uses $timestamp instead of NULL to reset delta_ts

Comment 25

[Dave Miller [:justdave]]

Comment on attachment 56996 [details] [diff] [review]
Patch v4

r= jake and bbaetz in IRC while bugzilla was down

Comment 26

[Dave Miller [:justdave]]

/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.105; previous revision: 1.104