Timestamp granularity


#1

Is there currently any way – or any plans to add – the ability to specify millisecond granularity for timestamps?

We’re attempting to deal with some concurrency control issues and right now it looks like timestamp-based concurrency control is the easiest path forward. The problem we face is that with second-level granularity, there’s always the possibility that a write was performed on GitHub after a write from our application and we cannot tell which write happened first. We would prefer not to propagate our write and allow GitHub’s write to win; i.e. last write wins, always.

In this scenario, let’s assume that our write happens at 12:00:00.001, and the write on GitHub at 12:00:00.999. The problem we face is that we only get 12:00:00 from the GitHub API, leaving us to be pessimistic about the timestamp and assume it is simply 12:00:00.0. GitHub’s event actually happened last, so our write should not even propagate to GitHub; our local data should be overwritten instead.

I don’t see any way right now to get millisecond-level accuracy. Is this possible or planned?

If not, is there a recommended way of dealing with this kind of concurrency control, where we cannot assume that GitHub’s data is the source of truth?

Thanks in advance!


#2

On reflection, this problem is even more problematic than I had first realized.

In the scenario above, if we decide that last write wins, then our records are now in a divergent state. GitHub has a different idea of what the record looks like than we do. We must assume that priority goes to the GitHub timestamp – in other words, the GitHub update represents the last update regardless – because the granularity is too wide.

Obviously, when last write wins, then a conflicting write must lose. It’s just unfortunate that in this case there is a non-zero chance that the write that wins is not actually last.

I also suspect that this problem goes potentially even deeper. If we received webhooks out of order for any reason, then there is no guarantee that we don’t receive two webhooks for the same record where the updated_at timestamp occurred at the same time. This can be mitigated somewhat by doing an explicit fetch back to the API again.

Very much looking forward to hearing thoughts on this from y’all.


#3

Hi, just wanted to check in on this again. Is there a different support channel I should be using for more time-sensitive questions? We’re a bit blocked on making some important design decisions since the answer here could sway us in largely different directions.