Closed Bug 1074077 Opened 10 years ago Closed 10 years ago

pushlog not updating since Friday evening PST time

Categories

(Tree Management :: Treeherder, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cbook, Assigned: mdoglio)

References

Details

Seems the pushlog stopped as example on m-c at https://tbpl.mozilla.org/?rev=16ff803b47a9 and so the next changes like the merge from Wes https://tbpl.mozilla.org/?rev=43ab820c7b68 is not displayed 

also happens on the other repos too, i guess thats a blocker :)
Severity: normal → blocker
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → All
Blocks: 1072291
Assignee: nobody → mdoglio
Status: NEW → ASSIGNED
On Friday we released some code that makes use of the fromchange parameter to fetch the pushlog. That replaces the former mechanism based on the last pushId fetched, using the same cache key but with a different type of data. On stage and prod the old data was still in cache and since the request was taking more than 30s to complete, the task was timing out. I fixed this just clearing the cache on stage and prod. I will open a PR to 
1 - increase the timeout for this kind of tasks
2 - add a clear_cache command to the update.py script for deployment
I will track this implementation in bug 1072291
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Actually the timeout was not a problem, I found out the json-pushes service returns a 404 if you call it passing a revision it doesn't know, like:
https://hg.mozilla.org/try/json-pushes?full=1&fromchange=60312e8eea30thisisunknown
but it returns a 200 with empty body if you use:
https://hg.mozilla.org/try/json-pushes?full=1&fromchange=123456
So the stale cache keys were not raising a 404 and so they were kept in cache.
You need to log in before you can comment on or make changes to this bug.