search

OpenBazaar / openbazaar-go

OpenBazaar 2.0 Server Daemon in Go
MIT License
993 stars 283 forks source link

Timestamps appearing incorrectly in client UI #1735

Open placer14 opened 4 years ago

placer14 commented 4 years ago

Brief Description: When chat messages are received by the client, they display as having originated in the past

Operating System (OS and version): Windows 7 64bit OpenBazaar version (shown on About OpenBazaar page in menu): 2.3.5 Hardware: n/a

Reproducible (Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce): Always

Steps to reproduce:

  1. Recieve message (unsure if direct or offline message)
  2. Observe the incorrect timestamp

Expected Behavior: Expected the timestamps to appear as time they were created.

Additional info (links, images, etc go here): Reported by fcl1892 in public slack

hoffmabc commented 4 years ago

Any diagnosis thoughts on this @placer14 @drwasho ?

jjeffryes commented 4 years ago

Is this a desktop client or a server issue? AFAIK, the desktop just displays the date it's given.

placer14 commented 4 years ago

I'm not sure if it's a desktop or server issue yet. Just wanted to be sure the desktop is included as part of the validation. This was observed in the desktop client, not Haven. This needs to be reproduced and triaged still.

jjeffryes commented 4 years ago

@placer14 it looks like this is a server issue. I can reproduce it on master, I'm getting data from the ob/chatconversations call like timestamp: "2148-06-08T12:06:10.442067968-05:00" which is incorrect.

jjeffryes commented 4 years ago

Digging into this more, it looks like only old messages are affected. New ones have the correct date.

Is it possible there was just a bad migration when we fixed this originally?

hoffmabc commented 4 years ago

I think it's possible that people ran new code before the repetitive migration issue was resolved.

placer14 commented 4 years ago

From the testing I did with a user in the public slack, they said they were with new messages. I didn't observe that for myself though.

pinheadmz commented 4 years ago

Getting this behavior consistently running server 0.13.5 on a raspberry pi (32-bit OS 😦). The hardware is 64 bit though, I plan on installing a 64-bit OS and trying that.

hoffmabc commented 4 years ago

Please let us know if that resolves it @pinheadmz thanks!

puxos commented 4 years ago

@pinheadmz Would a 64bit alpine based container running on raspberry pi a solution for you? If yes, i could do some research this weekend.

puxos commented 4 years ago

@pinheadmz Another possible reason is due to lack of RTC on a regular raspberry pi borad, the system time might need to sync thr ntp everytime you reboot the board. However i am not sure if this is the cause, just a guess. :)

pinheadmz commented 4 years ago

Ok it looks like a 64-bit OS is working better. I installed https://github.com/sakaki-/gentoo-on-rpi-64bit on my RPi along with go and pulled this repo from source. Biggest issue was installing tor on gentoo which I spent all day on and still couldn't resolve the openssl conflicts! 😡 I usually like to run my OB server in dual-stack mode, but for now clearnet-only is OK.

The reason I had to install from source is because the arm-5 binary in the release I believe is only 32-bit, and wouldn't run on 64-bit gentoo. The fact that this is an issue makes me think the arm-5 binary should not even be released anymore: is OB is officially 64-bit only since the bump up in timestamp precision?

placer14 commented 4 years ago

Thanks for the investigation. We're working through the tradeoffs of that decision (being officially 64-bit only versus investigating/fixing the 32-bit bugs and supporting both builds) internally and share our direction as soon as we know.

pinheadmz commented 4 years ago

I'm actually kinda surprised the behavior isn't handled gracefully by go or sqlite? If 32 bits are being truncated... is it truncating the wrong bits? The timestamps I ended up with in the database were very low or negative numbers, which the UI displayed as "50 years ago"

pinheadmz commented 4 years ago

p.s. Just to check a hunch I went back to the 32-bit OS and tried running from source instead of the binary, and the issue persists. I thought maybe it could be the build process or something, hoping that go and sqlite running on a 32-bit OS would handle UnixNano() better from this update but nope :-/

placer14 commented 4 years ago

Normally it is handled properly by go, but sqlite may not given the type in the table is an int and not a string or a blob. Not to mention it could be a typecast to a smaller precision type at any point in the path that handles dates. Thank you for the diligence around this bug. The low numbers are indicative of an overflow wrapping the value to something closer to 0. And since these are unix timestamps, they are anchored in 1970... roughly 50 years ago. :)

BTW, https://twitter.com/openbazaar/status/1181972135373426695

fcl1892 commented 4 years ago

Oh.Yesterday, these messages time were correct, but today they were incorrect. 2 files
1570723730(1) 1570802285(1)