Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(mobile): sync issue due to time mismatch #4659

Closed
wants to merge 8 commits into from

Conversation

fyfrey
Copy link
Contributor

@fyfrey fyfrey commented Oct 26, 2023

Currently, the app can get sync issues because of a time mismatch between server and client. This can both occur due to timezone changes or simply wrong clocks.

With this PR, the client retrieves the time for the next sync request from the server, thus solving the issue.

@vercel
Copy link

vercel bot commented Oct 26, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
immich ⬜️ Ignored (Inspect) Visit Preview Oct 26, 2023 4:37pm

Copy link
Contributor

@jrasm91 jrasm91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk if this solves the problem either. The issue is the database may be in a different timezone than the server still. Really we should just send accurate timestamps with timezones

@@ -4,6 +4,7 @@ import { extname } from 'node:path';
import pkg from 'src/../../package.json';

export const AUDIT_LOG_MAX_DURATION = Duration.fromObject({ days: 100 });
export const AUDIT_LOG_CLEANUP_DURATION = Duration.fromObject({ days: 101 });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? Is this an attempt to resolve a potential issue with time differences between the server and the database?

Copy link
Contributor Author

@fyfrey fyfrey Oct 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah. it's simply being cautious. keep stuff for 1 day longer than needed if everything works perfect with the machine clocks and timezones

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While that sounds reasonable, I'd much rather be accurate. If we were accurately requesting the change log, this would be unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true. better safe than sorry for now?

@fyfrey
Copy link
Contributor Author

fyfrey commented Oct 26, 2023

Idk if this solves the problem either. The issue is the database may be in a different timezone than the server still. Really we should just send accurate timestamps with timezones

dates between app/server are now always in UTC; the server and datebase use timestampz which has timezones.. so it should be good?

@jrasm91
Copy link
Contributor

jrasm91 commented Oct 26, 2023

Idk if this solves the problem either. The issue is the database may be in a different timezone than the server still. Really we should just send accurate timestamps with timezones

dates between app/server are now always in UTC; the server and datebase use timestampz which has timezones.. so it should be good?

When we serialize a date and send it over json we're already using the ISO 8601 which is a timezone aware representation of the date and time. If this was passed along correctly to the database everything would be fine, so something is obviously not working correctly. My suspicion is TypeORM is adjusting the time, since JS Dates are only internally stored as numbers and have no sense of timezones. I believe it is offsetting it (incorrectly) to UTC.

https://github.com/typeorm/typeorm/blob/master/src/util/DateUtils.ts#L45-L80.

@fyfrey
Copy link
Contributor Author

fyfrey commented Oct 26, 2023

When we serialize a date and send it over json we're already using the ISO 8601 which is a timezone aware representation of the date and time. If this was passed along correctly to the database everything would be fine, so something is obviously not working correctly. My suspicion is TypeORM is adjusting the time, since JS Dates are only internally stored as numbers and have no sense of timezones. I believe it is offsetting it (incorrectly) to UTC.

https://github.com/typeorm/typeorm/blob/master/src/util/DateUtils.ts#L45-L80.

I see, typeORM doing random stuff again.
It could also use SystemTime instead of UTC (which might be different on the systems....)
I guess this would affect quite a lot of (our) code. Not sure how to fix this. Needs another PR

@jrasm91
Copy link
Contributor

jrasm91 commented Oct 26, 2023

A bigger change I am thinking about is switching to luxon date objects, to which you can do with custom type parsers. I wonder if we left it as a raw string if that would fix this endpoint at least.

@fyfrey
Copy link
Contributor Author

fyfrey commented Oct 27, 2023

We mount /etc/localtime:/etc/localtime:ro for server and microservices, but not for the database container. Maybe this leads to issues? Because I've never encountered any sync errors.. but I also run the postgres database on the host (thus it has the same /etc/localtime)

@jrasm91
Copy link
Contributor

jrasm91 commented Oct 27, 2023

Right if local time is the same it is never an issue. It should not be a requirement that the client, server, and database are on the same timezone though. I'm guessing this can be reproduced by having the client and server on different timezones.

@alextran1502
Copy link
Contributor

Hi Fynn, do you think we still need this PR?

@fyfrey
Copy link
Contributor Author

fyfrey commented Nov 20, 2023

Yeah, it's still an issue. I'll rebase and make some changes.

@fyfrey
Copy link
Contributor Author

fyfrey commented Nov 29, 2023

rebased and made sure the app always uses the server time when possible

So, this PR guards against sync issues originating from time divergence between client and server, e.g. due clock resets or timezone changes

Copy link
Contributor

@jrasm91 jrasm91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine merging it as is. I think we still need to look at how dates get translated between the API body, server, and database, especially when the server and database are in different timezones, but this can be used in the meantime.

server/src/domain/audit/audit.service.ts Outdated Show resolved Hide resolved
Copy link

cloudflare-pages bot commented Mar 8, 2024

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: d8413ea
Status: ✅  Deploy successful!
Preview URL: https://668752b9.immich.pages.dev
Branch Preview URL: https://dev-fix-sync-time-mismatch.immich.pages.dev

View logs

@jrasm91
Copy link
Contributor

jrasm91 commented Apr 27, 2024

Superseded by #9100 and others

@jrasm91 jrasm91 closed this Apr 27, 2024
@alextran1502 alextran1502 deleted the dev/fix-sync-time-mismatch branch May 3, 2024 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants