bug: We sometimes see `last_message_at` of `1754-08-30T22:43:41.128Z`

[puellanivis]

Describe the bug

We sometimes see channel.state.last_message_at with a value of 1754-08-30T22:43:41.128Z

To Reproduce

channel = stream.channel("messaging", conversation_id, {
  "members": user_ids.map ( el ) -> el.toString()
})

channel.create()
.then -> announce_start_of_conversation(user_ids, conversation_id)
.delay 300
.then ( res ) ->

  await channel.watch()

  read_times = (ramda.values channel.state.read).map (el) -> el.last_read

  read_times[0].should.be.gt channel.state.last_message_at
  read_times[1].should.be.gt channel.state.last_message_at

Expected behavior

channel.state.last_message_at should contain a sane value or be undefined, instead it gives us a datetime of 1754-08-30T22:43:41.128Z.

Oddly, this time corresponds to the signed 64-bit integer wrap around of the number of nanoseconds 0001-01-01T00:00:00Z is before Unix epoch, and the only language I know of that requires any such conversion is Go. But we’re not using and Go code here.

I’m trying to figure out how I should fix our flaky test in this situation, or do we just need to use a form of while (channel.state.last_message_at is before 1755) { wait_for_next_update() }?

It would be so much better if we never got sent this Go time.Time{}.UnixNano() value in the first place, at least in that case we would be able to have a more robust and reliable while (channel.state.last_message_at is undefined) { … }.

Client (please complete the following information):

• OS: NodeJS on alpine
• Alpine Version: 3.12
• NodeJS Version 12.19.1

Additional context

Add any other context about the problem here.

[petyosi]

@puellanivis this is related to our backend implementation, can you please contact us at [email protected]? We will take it from there.