REST BzAPI sometimes returns dates in the future (possibly only for history items)

RESOLVED FIXED

Status

Webtools
BzAPI
--
critical
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: christian, Assigned: gerv)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
+++ This bug was initially created as a clone of Bug #578556 +++

This problem looks to be back. Observe:

https://api-dev.bugzilla.mozilla.org/latest/bug/604146?content-type=text/html&include_fields=_default,history

has a history item with change_time of 2010-11-09T05:36:27Z (which is tomorrow)

but last change time is 2010-11-08T21:36:27Z (while today, it is still in the future)
To help in prioritizing this bug fix, it's my understanding that this bug is currently (almost?) entirely preventing the Bugzilla portion of pulse from working.

This, in turn, is impeding development on some review turnaround code that I'm trying to move forward.
(Reporter)

Comment 2

7 years ago
Oh, I'll attempt to work around it today then
Fantastic; thanks!
(Assignee)

Comment 4

7 years ago
I'll try and fix it from my end too.

When you are reading BzAPI code, it may help you to know that, even though b.m.o. is 3.6, it's currently configured in the BzAPI config as 3.4. (This affects the time conversion code.) The reason for this is that it avoids another bug which caused certain kinds of search, including one used by the Bugzilla Dashboard to make requests for every bug in Bugzilla!

Atul: can you please switch the Bugzilla dashboard flag assignee query from using the shortcut "name=value" syntax to using the boolean chart syntax? I.e. instead of flag.assignee=gerv@mozilla.org, switch to field0-0-0=flag.assignee and so on.

That will avoid it triggering the bug, which allows us to switch back to marking b.m.o. as 3.6, which might be required to fix this bug.

Gerv
Interestingly, at this moment, viewing any bug history URL in the browser which has produced nicely formatted JSON in the past, such as

https://api-dev.bugzilla.mozilla.org/latest/bug/599119/history

is currently generating this output:

--- 
code: ~
error: 1
message: "Unknown error: 500 Internal Server Error"

Perhaps these failure modes are somehow related?  Or should I spin up a separate bug for that?
(In reply to comment #5)
> code: ~
> error: 1
> message: "Unknown error: 500 Internal Server Error"
Sounds like bug 611689.
(Assignee)

Comment 7

7 years ago
OK, the problem is that there's a bad version of SOAP::Lite which breaks Bugzilla's XML-RPC API. We downgraded to a safe version on the SJC webheads, but apparently not on the PHX ones (which BzAPI was set to talking to recently for other reasons). Those reasons have now gone away, so I've changed BzAPI to talk to the SJC webheads again, and the history URL given above is now working. Meanwhile, justdave is working on fixing SOAP::Lite on the PHX webheads.

Let us now return to our regularly-scheduled subject for this bug (dates in the future) :-)

Gerv
(Assignee)

Comment 8

7 years ago
I'm still working on this, but here's my shot in the dark: if you are using the BzAPI with an account which has the "timezone" user preference set to anything other than "Default (server time)", set it to that, and see if the problem goes away.

Gerv
(Reporter)

Comment 9

7 years ago
Nope, I'm not using it with an account.
(Assignee)

Comment 10

7 years ago
OK, I _think_ I've fixed this. I had told BzAPI that b.m.o. was 3.4 rather than 3.6 to work around another bug; however, that caused it to calculate timestamps incorrectly. I've just released 0.8, and told BzAPI (on /0.8 and /latest, but not /0.7) that b.m.o. is 3.6. This should mean the timestamps are now right.

I'm not resolving this FIXED till I get a chance to test carefully, but I have to go out. However, feel free to test yourselves :-)

Gerv
(Reporter)

Comment 11

7 years ago
At first glance this does indeed looked fixed, but I need to check it out some more as well.

I'll likely set up a pulse consumer that looks for timestamps in the future and sends me an email when it detects one.
(Assignee)

Comment 12

7 years ago
clegnitto: That would be awesome. Statistically, you should also expect to see many event timestamps pretty close to the time the mail arrives, but just in the past. If the peak of timestamps is, e.g. 8 hours before or 7 hours before, that's probably another bug.

dmose: are you all set?

Gerv
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

7 years ago
As of now, https://api-dev.bugzilla.mozilla.org/latest/bug/604146?content-type=text/html&include_fields=_default,history

says:

creation_time:    2010-10-13T20:13:00Z
last_change_time: 2010-11-08T21:36:27Z
history: 
  - 
    change_time:  2010-11-08T21:36:27Z
    ...

Looking at the web UI for bug 604146, it says:

Reported:  	2010-10-13 13:13 PDT => 2010-10-13 20:13 GMT
Modified: 	2010-11-08 13:36 PST => 2010-11-08 21:36 GMT

and the history change time is

2010-11-08 13:36:27 PST => 2010-11-08 21:36:27

And that matches the BzAPI output above. So I am tentatively declaring this bug FIXED. Remember, you need to use /latest or /0.8.

Gerv
My BugzillaConsumer for pulse that is subscribed to "#" (i.e. everything) has not gotten any notifications in the last 10 minutes, which makes me suspect that either this isn't fixed, or (more likely, I suspect) that the deployed pulse service is still looking at the old API.
(Reporter)

Comment 15

7 years ago
I'll look into it. There's actually a pulse component now in webtools as well :-)
You need to log in before you can comment on or make changes to this bug.