[HOLD #227234] Receiving Notifications from chats sent months ago

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Go to a chat with Gabi
2. Start chatting

Expected Result:

Notifications received would be from our chats happening now

Actual Result:

Received notifications from chats received months ago. When I look at those chats they also show “Invalid Date”

Workaround:

unknown

Platform:

Where is this issue occurring?

• Desktop App

Version Number: 1.2.30-0
Reproducible in staging?: Needs reproduction
Reproducible in production?: Needs reproduction
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: @garrettmknight
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1669654070339909

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[garrettmknight]

Updated to v1.2.33-7, 'invalid date' persists:

[dylanexpensify]

working on reproducing now

[dylanexpensify]

@garrettmknight is this only with your chat with Gabi?

[garrettmknight]

There's another chat with her that has the 'Invalid Date' text on the same day, but no others.

[garrettmknight]

Happened to @RobertLadue as well:

[marcaaron]

possible theory - something in the API layer changed and is sending an invalid action.created

We render the date here ->

App/src/pages/home/report/ReportActionItemDate.js

Lines 15 to 19 in 820e876

	const ReportActionItemDate = props => (
	<Text style={[styles.chatItemMessageHeaderTimestamp]}>
	{props.datetimeToCalendarTime(props.created)}
	</Text>
	);

So like the UI says it is probably invalid...

Seeing the browser notifications makes sense too since we use the created field to determine whether to show a notification. The created being invalid means the front end interprets it as "new"

App/src/libs/actions/Report.js

Lines 1330 to 1331 in 820e876

	// If we are past the deadline to notify for this comment don't do it
	if (moment.utc(moment(action.created).unix() * 1000).isBefore(moment.utc().subtract(10, 'seconds'))) {

IMO this is in part of a consequence of this issue (needs a better general design) and in part due to some API change that we haven't connected to this bug yet (which seems more urgent to solve).

[dylanexpensify]

Ah very interesting @marcaaron. Should we put this on hold then while we work on the linked issue? Or can we work on this externally in the meantime?

[marcaaron]

I don't think it should be on HOLD, no. It seems like an API change has triggered this and we should make this Internal so someone on the team can prioritize it.

[dylanexpensify]

Sounds good! Thanks!

[arosiclair]

I'll take a stab at tracing where this API issue could be coming from

[dylanexpensify]

Amazing, thanks @arosiclair !

[dylanexpensify]

@arosiclair any update here?

[arosiclair]

Not sure where this could be coming from but here's what I've found so far.

Several months ago we started using timestamps with millisecond precision in this PR. At the time we weren't depending on the created timestamp very much. This was deployed on Aug 29th.

A couple weeks ago we changed logic on how we generate and use created timestamps in NewDot in this PR. These changes were deployed in v1.2.30 which matches the affected versions in the OP.

If these were breaking changes, I'd think old messages sent before the above deploys would have this Invalid Date issue but that isn't the case for me. I've also tried trimming off the millisecond portion of the created string to reproduce Invalid Dates in dev but that didn't cause any issues.

@luacmartins @roryabraham @tylerkaraszewski Any ideas if they (or anything else) might be the source of this issue?

It might also be worth running a CQ to find what the created timestamps on these report actions actually look like in the DB.

[dylanexpensify]

bump @luacmartins @roryabraham @tylerkaraszewski ?

[dylanexpensify]

@arosiclair any updates by chance?

[arosiclair]

Only path forward I see is getting affected reportIDs and running a CQ to see what these invalid created values look like. That should give us a hint as to what the issue is.

@garrettmknight @RobertLadue @joekaufmanexpensify could you share the report IDs for the chats you guys experienced this Invalid Date issue? You can open the chat in web and grab the ID from the URL here

[luacmartins]

Sorry I completely missed the ping here. It seems like the PRs Andrew linked are probably the cause. I agree that we could run a CQ to get the created dates for those reports to see how we are storing the date and then fix it.

[joekaufmanexpensify]

I know I did experience this issue at some point in the past, but I don't remember which report, and didn't record it. Sorry! For me, signing out and back in resolved the issue at the time.

[melvin-bot]

@arosiclair, @dylanexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[arosiclair]

No real updates atm. Signing out and back in resolving the issue suggests that Onyx might have had an invalid created value cached and the API was only able to replace it with a valid one after signing out and clearing Onyx.

Bumping @garrettmknight @RobertLadue for those report IDs

[JmillsExpensify]

A couple of things:

• Given the relation to sequence numbers PRs, I'm going to proactively add a HOLD on that project and simultaneously take this issue over (I'm the BZ person assigned and responsible for SQN bugs).

• Let's still have @garrettmknight and @RobertLadue share their reportIDs when they are both back from vacay.

• Even then, given that signing in and out resolves the issue, that indicates that this is temporary, so I could equally see the argument that we should close this for focus. Leaving that up to @arosiclair.

[arosiclair]

Yeah let's just close this out for now as this may never come up again after sequence numbers is finished. If it does, we can just reopen and take another look.