Incorrect title and link for batch-modify events in timeline rss

[Jun Omae]

I've updated tickets using batch-modify feature at 2013-08-30T19:38:30+09:00. The title and link of the event are correct in timeline page. However, the title and link are incorrect in timeline rss. The ticket id are repeated in the title and link.

In timeline page:

• title: Tickets #5499,​8813,​10740,​11219 batch updated by jomae
• link: http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C11219

In timeline rss:

• title: Tickets #5499,​8813,​10740,​10740,​11219,​11219 batch updated
• link: http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219

    </item><item>
      <title>Tickets #5499,​8813,​10740,​10740,​11219,​11219 batch updated</title>
      
        <dc:creator>jomae</dc:creator>

      <pubDate>Fri, 30 Aug 2013 10:38:30 GMT</pubDate>
      <link>http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219</link>
      <guid isPermaLink="false">http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219/1377859110243015</guid>
      <description></description>
      <category>batchmodify</category>
    </item><item>

I don't know whether or not we can reproduce with 1.0-stable.

[Ryan J Ollos]

I've noticed this issue on t.e.o as well. Possibly related, my RSS reader (feedly) shows repeated entries for a batch modification change. Here is a recent example (timeline:2013-10-09T22:47):

• 19 hrs ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​7343,​​8269,​​8289,​​8336,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated
• 1 day ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​5640,​​6007,​​6007,​​6143,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated
• 1 day ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9215,​​9976,​​10727,​​11026 batch updated
• 4 days ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026,​​11026 batch updated
• 5 days ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​7343,​​8269,​​8289,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated

There are more entries going back farther. Note that each RSS event has different duplicate tickets.

I haven't been able to reproduce the issue in a development environment. Looking at the code, it is rather strange that the timeline and RSS entries would be different, since each is generated by calling event.render:

• tags/trac-1.1.1/trac/timeline/templates/timeline.html@:47,49#L40​
• tags/trac-1.1.1/trac/timeline/templates/timeline.rss@:20,22-23​

[Jun Omae]

I suppose that the query in produce_ticket_change_events() should be the following at source:tags/trac-1.0.1/trac/ticket/web_ui.py@:294-299,305#L290​.

trac/ticket/web_ui.py

@@ -296 +296 @@
                     FROM ticket_change tc
                         INNER JOIN ticket t ON t.id = tc.ticket
                             AND tc.time>=%s AND tc.time<=%s
-                    ORDER BY tc.time
+                    ORDER BY tc.time, tc.ticket
                     """ % (ts_start, ts_stop)):
                 if not (oldvalue or newvalue):
                     # ignore empty change corresponding to custom field

The produce_ticket_change_events() iterates ticket.id and time for each ticketmodify. However, the query sorts only ticket_change.time. If the query returns the following, the same ticket id is returned more than once.

ticket      time              author      field       oldvalue    newvalue
----------  ----------------  ----------  ----------  ----------  ----------
3           1382348110040725  jun66j5     cc                      jun66j5
5           1382348110040725  jun66j5     cc                      jun66j5
6           1382348110040725  jun66j5     cc                      jun66j5
3           1382348110040725  jun66j5     comment     2
5           1382348110040725  jun66j5     comment     5
6           1382348110040725  jun66j5     comment     3

[Peter Suter]

Interesting. Nice catch. I don't understand why only RSS is affected though.

[Jun Omae]

The issue depends on range for ticket_change.time and database backend. If the range is narrow, it rarely happens. Proposed fix and unit tests can be found in [1e458e62f/jomae.git].

If without the fix, TicketModule.get_timeline_events() for batch-modify returns duplicated ticket.id.

$ PYTHONPATH=. ~/venv/py25/bin/python trac/ticket/tests/batch.py
.........................F
======================================================================
FAIL: Regression test for #11288
----------------------------------------------------------------------
Traceback (most recent call last):
  File "trac/ticket/tests/batch.py", line 301, in test_timeline_events
    self.assertEqual(ids, sorted(batch_ev[3][0]))
AssertionError: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20] != [1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5,
6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 8, 9, 9, 9, 9, 10, 10, 10, 10, 11, 11, 11,
11, 12, 12, 12, 12, 13, 13, 13, 13, 14, 14, 14, 14, 15, 15, 15, 15, 16, 16,
16, 16, 17, 17, 17, 17, 18, 18, 18, 18, 19, 19, 19, 19, 20, 20, 20, 20]

----------------------------------------------------------------------
Ran 26 tests in 1.553s

[Peter Suter]

Ah, so it only occurs more often on RSS, because the default daysback parameter is larger there. But Timeline page can also trigger this (scroll down to August 30.) depending on daysback and from and bad luck / database backend.

Thanks for looking into this!

[Jun Omae]

Committed in [12201] and merged into trunk in [12202].

[Peter Suter]

Today I saw something like this again:

Tickets #10487,​​10487,​​10838,​​11479,​​11479 batch updated

And yesterday as well:

Tickets #736,​​736,​​1209,​​1414,​​2078,​​2168,​​2454,​​3238,​​3343,​​3343,​​3644,​​3644,​​3745,​​3947,​​4794,​​7386,​​7388,​​7728,​​7893,​​8727,​​9168,​​9570,​​9947,​​10091,​​10350,​​10600,​​10742,​​10742,​​11050,​​11166,​​11166,​​11283,​​11304,​​11334,​​11346 batch updated

[Ryan J Ollos]

I see a lot of duplicate RSS feed entries (and duplicated tickets in each RSS message) from t.e.o since it is still running a rather old version of 1.1.2dev (from 15 June 2013).

[Peter Suter]

Oops, I mistakenly assumed t.e.o. already runs this fix "because 1.0.2 < 1.1.2", but that's of course nonsense. Sorry for the noise.

[Ryan J Ollos]

It would be great to get t.e.o upgraded though, so we can confirm some of the fixes that have been put in place.

[Christian Boos]

Agreed… it's done now (r12584).

[Ryan J Ollos]

It looks like there might be a problem with the repository caching. I committed [12585:12587], but the changesets are not shown yet in the repository browser.

[Jun Omae]

milestone:1.1.2 said This Trac instance is using Trac 1.1.2dev-r11682, Genshi 0.7dev-r1134 and Babel 0.9.6. I just modified it to r12584.

[Christian Boos]

Replying to rjollos:

It looks like there might be a problem with the repository caching. I committed [12585:12587], but the changesets are not shown yet in the repository browser.

Right, there was, and it's fixed now (we used to also have the 1.0-stable's trac-admin notify the 1.1 envs of added changesets, which no longer works now that there's been an environment upgrade).