Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#10132 closed defect (fixed)

Trac Timeline broken

Reported by: bastik Owned by: erinn
Priority: Medium Milestone:
Component: Internal Services/Service - trac Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

https://trac.torproject.org/projects/tor/timeline

Shows the following Trac Error:

Event provider ChangesetModule failed for filters "Changesets in all repositories", " - arm", " - torbutton", " - stem", " - pluggable-transports/obfsproxy", " - tor", " - torbrowser", " - builders/tor-browser-bundle": ValueError: need more than 0 values to unpack

https://trac.torproject.org/projects/tor/timeline?wiki=on&ticket=on&milestone=on works (changesets are not enabled here)

Child Tickets

Change History (15)

comment:1 Changed 7 years ago by bastik

It appears to be stem.

Event provider ChangesetModule failed for filters " - stem": ValueError: need more than 0 values to unpack

I can enable any changeset, but when I enable all of them (Changesets in all repositories) I get an error. When I enable stem I get the error above.

The latest changeset for Tor is from 11/07/13, so it can show changesets and it doesn't just trigger for changesets supposed to be displayed.

comment:2 Changed 7 years ago by atagar

Hi helix, pushed the no-op commit you requested.

comment:3 Changed 7 years ago by bastik

Using the default link (logged out and/or cookies cleared) to the timeline (see first link from description or "timeline" in NavBar), which has all repositories enabled the error does *not* occur.

When changing the days, the timeline goes back (from default 5) to 7 (probably 8 tomorrow) an error appears. Going back and disabling the changeset for 'stem' does solve this issue.

Going back again and enabling changeset for 'stem' result in an error.

Event provider ChangesetModule failed for filters " - arm", " - torbutton", " - stem", " - pluggable-transports/obfsproxy", " - tor", " - torbrowser", " - builders/tor-browser-bundle": ValueError: need more than 0 values to unpack

Enabling 'stem' alone gets almost the same error, it just lists 'stem' (when enabling others separately [partly tested] no error seems to trigger)

Event provider ChangesetModule failed for filters " - stem": ValueError: need more than 0 values to unpack

Last edited 7 years ago by bastik (previous) (diff)

comment:4 Changed 7 years ago by erinn

bastik,

You seem pretty good at this. I tried to figure out what was in stem's repository that was making trac so angry but I haven't figured it out yet. While searching for more info it became clear that the git plugin is in some way at fault, combined with some kind of odd commit... but I don't know where! Is there anything I can do to help you figure it out?

comment:5 in reply to:  4 Changed 7 years ago by bastik

Replying to erinn:

bastik,

You seem pretty good at this.

I saw this bug and reported it, because it could have been something that sticks around longer. I tried to look into it and see what it takes to show the error(s). It was some testing of combinations, where luckily the only thing that triggered it involved 'stem' and was only 'stem' (instead of some odd combination).

I was about to close this, before I tried to go back more days than the default 5. No "investigation" was made since my last reply to this ticket. Mostly because I don't know what could be wrong. So, I wouldn't call myself good at this, but I hope to have been helpful.

I tried to figure out what was in stem's repository that was making trac so angry but I haven't figured it out yet. While searching for more info it became clear that the git plugin is in some way at fault, combined with some kind of odd commit... but I don't know where!

I can have a look, but don't think I'll have any clue what's wrong.

Is there anything I can do to help you figure it out?

This would require some knowledge or clue about what could cause this, on my end. So, currently there would be nothing that would help, I think.

Since this bug doesn't trigger for people visiting the default timeline, since it should now only occur if one increases the number of days the timeline goes back, the bug is not that annoying, though the reason should be found (or its cause) in order to prevent it from appearing again at a later point.

My plan (for tomorrow, I guess) will be to figure out on which day the bug triggers and what commits have been made to 'stem' on that day. Then compare the commits with each other, then maybe with one from the next day since there's no commit that triggers the error.

If you got some ideas how to approach this, please let me know.

comment:6 Changed 7 years ago by erinn

I looked into it a bit more and the bug triggers on Nov 9th from stem, which has 4 commits. You can see them more easily listed here:

https://gitweb.torproject.org/stem.git

As long as Timeline's range does not include Nov 9th, the bug isn't triggered. So what's causing it? Some kind of malformed git commit that GitPlugin is unable to handle. My guess is that it is the merge commit, because some of the things I have read online indicate that at least in the past GitPlugin has had issues with certain types of merges. I don't know what's special about that merge though, so I could be wrong. But it is definitely something in those 4 commits that triggers it.

If you want to look into it more, that's where I'd start -- trying to find other people online who had the same issue and if you know Python and/or git to look at the source code and the commits in question and see if maybe it becomes more clear where something went wrong. (We can patch GitPlugin to not have this issue if we figure it out.)

comment:7 Changed 7 years ago by atagar

As long as Timeline's range does not include Nov 9th, the bug isn't triggered.

Interesting. In that case I'd mostly suspect the 1.1.1 tag being the issue. Does it also happen for October 13th (when I tagged 1.1.0)?

comment:8 in reply to:  7 Changed 7 years ago by bastik

Replying to atagar:

As long as Timeline's range does not include Nov 9th, the bug isn't triggered.

Interesting. In that case I'd mostly suspect the 1.1.1 tag being the issue. Does it also happen for October 13th (when I tagged 1.1.0)?

13th Oct. with 0 days back (or some days back) = no error for me
9th Nov. with 0 days back = I see an error
9th Nov. with 0 days back and changesets disabled for 'stem' = no error for me

comment:9 Changed 7 years ago by bastik

I think it is commit c27dc313c0ead935bbc71e8b92938fe4a4b18168.

What helped me to get to this conclusion is the 'Browse Source' thing of trac, (where I sent an email to the list asking for how to handle that thingy, but got no reply.) (I created a ticket to add the link to gitweb.tp.o back to the navigation, to have both.)

I still don't know how to handle 'Browse Source', but it can do something.

Here is the commit above viewed in the source browser and for me it spits an error:

Trac detected an internal error:

ValueError: need more than 0 values to unpack

[...]

The action that triggered the error was:

GET: /changeset/c27dc313c0ead935bbc71e8b92938fe4a4b18168/stem

For comparison other commits like b1fb3e7a2cbbef029f483f084da98940844a3058 looks like this. In fact all commits of that day, beside the one with an error, gets displayed fine. In order to check, replace the commit inside the URL. (If you pick an invalid one it will give you an error that the changeset number is invalid)

Trac could have us told earlier which changesets made it unhappy. Since the error in the source browser tells what triggers the error, the timeline feature could have been equally nice.

Gitweb shows it like that.

It might be the case that this is because there is no description (not the header, but what's below) for what has changed or that there are two diffs for

 'stem/__init__.py'

The first might not be the case since a Tor commit has no description as well. I haven't found a commit with diff1 and diff2, yet. That might be the cause.

comment:10 Changed 7 years ago by erinn

Okay, with boklm's help on IRC we figured out the problem: http://trac.edgewall.org/ticket/10676

The commit in question has the mergetag object. Two good things here:

  1. the bug is fixed!
  2. in a version of trac that we can upgrade to!

I asked weasel and he said he's cool with installing the package if I deal with the fallout, so while I am not going to do that right this second, I should be able to do it within the next week.

comment:11 in reply to:  10 Changed 7 years ago by bastik

Replying to erinn:

Okay, with boklm's help on IRC we figured out the problem: http://trac.edgewall.org/ticket/10676

I could have entered there error message I got into a search engine of my choice. Strangely I didn't.

The commit in question has the mergetag object. Two good things here:

  1. the bug is fixed!
  2. in a version of trac that we can upgrade to!

Cool.

I asked weasel and he said he's cool with installing the package if I deal with the fallout

Cool, and always remember being exposed to radioactive fallout doesn't make you radioactive yourself. (The more you know....)

[...] I should be able to do it within the next week.

That sounds reasonable. I don't thing most people will modify their timeline settings to include more days. Well I don't know how common the feature is.

Thank you all for figuring out what's broken. Thanks for installing, weasel. Thanks for dealing with fallout (whatever that is in this case) Erinn.

comment:12 Changed 7 years ago by erinn

Resolution: fixed
Status: newclosed

Okay, we upgraded trac to 1.0 and now the Timeline issue is fixed. I assume other things will be broken, though, so please file bugs to let me know what they are. :) Thanks for all your help, bastik!

comment:13 Changed 7 years ago by bastik

Thank you for upgrading Erinn and weasel.

I can confirm that the bug is gone now. (I just hoped it would be a Tor bug I would have hunted down.)

I saw this ticket at work, where I've got an IE and nothing looked so round as it does right now. The navigation bar looks buggy in IE, there are two black horizontal bars up to "view tickets" and then they stop and the sections (view ticket/timeline etc) are separated by vertical bars. It looks like something is missing. Nothing I complain about, nothing I care about. (Wouldn't call it a bug either)

comment:14 Changed 7 years ago by erinn

Yeah, I am not really feeling the new styling going on here, but I don't know if I have enough time or inclination to dig into the CSS right now. Thanks for the feedback on appearance.

I'm sure you can still find plenty of bugs to hunt down. :)

comment:15 Changed 5 years ago by qbi

Component: TracService - trac

Move all tickets from trac to "Service - trac" component.

Note: See TracTickets for help on using tickets.