History not updating when client time ahead of server time

[mvdbeek]

This is with release_16.04 and OSX / chrome as client.
To reproduce, set the clock a few minutes ahead of the server time and run a tool.
Notice that the history never refreshes (past the initial "grey state" ). I guess this is related to #1788
Setting the clock to the correct time fixes this, but unfortunately our university's firewall is blocking access to apple's time server, so this is a bit annoying.

Ping @carlfeberhard, do you have any idea how to make this more robust ?

[jmchilton]

Ping @natefoo - this explains the history behavior you were seeing potentially.

[martenson]

this needs to be ported to 16.04 but is not blocking the release afaik, so I changed the milestone

[mvdbeek]

okay, so this also happens on linux (with chrome), with client and server on the same machine. Again, setting the time back a few minutes fixed it.

[carlfeberhard]

@mvdbeek No way robustly work around incorrect client time as far as I can tell, unfortunately. Changing strategies wouldn't make for great backporting either, but is something I may be able to get to in 16.07.

Are you still having the issue? does it ever occur when the machines have correct time? Does your university have it's own ntp server?

@jmchilton do you have a link to that behavior?

[mvdbeek]

Are you still having the issue?

Yes, if I set my time back to the future.

does it ever occur when the machines have correct time?

Nope, I haven't noticed this when the time is correct. I mean this is not a problem if you know it, but if you don't you might get the impression something is wrong.

Does your university have it's own ntp server?

Yes, though I doubt our users have ever heard of NTP.

No way robustly work around incorrect client time as far as I can tell, unfortunately. Changing strategies wouldn't make for great backporting either, but is something I may be able to get to in 16.07.

That's too bad. Is there maybe a way to detect that the client time is wrong and warn the user of this?
Couldn't galaxy itself respond with the current time somehow?

[dannon]

First thing that comes to mind as a possible bandaid (and I get why it's not super robust) would be to just use some minimum interval if the time is from the future. So, If I request history updates filtered since 2017 (or whatever future date), Galaxy could change it to (serverside) now() - 5 minutes or some appropriate interval, whatever the history default is.

[carlfeberhard]

Is there maybe a way to detect that the client time is wrong and warn the user of this?
Couldn't galaxy itself respond with the current time somehow?

@mvdbeek There may be something that can be done with the response date header.

@dannon I guess I don't understand: I don't think we should make the API update filter inaccurate (-x time) just to solve this and the general notion of slop just kind of defers the problem to truly incorrect clocks. But I'll see if something like ( updated since date header - slop ) would work without screwing over people with accurate time.

[dannon]

@carlfeberhard Hrmm, yeah, I get how it might be seen as making the response inaccurate, if more useful to the primary galaxy web client. I guess prior to even querying the datasets it should just compare timestamps and reply with an error, since it's invalid to ask for data from the future. That'd save a db query in any event.

As far as the particular error, maybe the better long term solution is to just have the client and server handshake on a timestamp that gets used for sorting out these deltas, so the client is able to make appropriately time-framed requests.