[eszter007]

PUT /api/v1/progress always stored the time of the request. That's right for a reader, which syncs while you read. It's wrong for a client that syncs later, like a script that runs every hour and copies over where you got to. Something read at 7:10 then shows up in the reading timeline at whatever time the script ran, and "newest wins" treats it as newer than it is.

This lets the client send timestamp (unix seconds) with the position, and the server stores that instead. The progress row, the progress log behind the timeline, and auto-finish all use it. Change sequence numbers aren't affected, so incremental sync feeds keep working the same.

Some limits so a bad clock can't do damage:

• A time in the future is capped at now.
• A missing time, or anything before 2000 (an unset clock), means now.
• Only PUT /api/v1/progress reads it. PUT /syncs/progress and the batch route keep using the time of the request, since those are what readers use and a reader's clock isn't always set.

Testing

test/progress-client-time.test.ts covers:

• a past time stored and showing up on the right day in the activity stats
• a future time capped
• a string or tiny number falling back to now
• a backdated position not beating a newer one from another device
• the kosync route ignoring the field

Without the change in kosync.ts the test fails. The full suite passes (689 tests), and so does tsc --noEmit. The API docs are updated.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

The v1 progress route now accepts valid client-supplied Unix timestamps for reading positions. The parser caps future values at the current time and uses the current time for missing or invalid values. The sync and batch routes continue to use request time.

Changes: Progress timestamp handling

Layer / File(s)	Summary
Parse and verify client timestamps src/routes/kosync.ts, src/routes/v1/progress.ts, test/progress-client-time.test.ts, docs/API.md	The parser accepts an optional client-time setting. The v1 progress route enables it. Tests cover past, future, string, and pre-2000 timestamps, along with progress selection across devices and kosync behavior. API documentation describes the timestamp rules and distinguishes the sync and batch routes.

Priority: Not assessed

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Suggested reviewers: itsthisjustin

Merge Risk: Moderate · up to 04649

A delayed or backdated progress write from the same device can replace that device's newer reading position, so users may lose their latest position. Guard the conflict update on the timestamp before merging.

- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-24T18:58:42.599039Z We couldn’t complete this review. Comment @codex review to try again.	04649a1	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.