Submitting highlights will always changed updated_at field, even when a no-op is expected

[marcus-crane]

Discussed in #78

^{Originally posted by BrandonNoad February 14, 2023}
Hi.

Is it possible to not update the updated_at value for highlights that have already been imported?

I assume the updated_at value is set by the Readwise API and is not something October is able to control. But, updating the updated_at value for existing highlights every time you perform a sync conflicts with the recommended export method (GET https://readwise.io/api/v2/export/):

The recommended way to use this endpoint is to first sync all of a user's historical data by passing no parameters on the first request, then pageCursor until there are no pages left. Then later, if you want to pull newly updated highlights, just pass updatedAfter as the time you last pulled data.

Changing the updated_at value for highlights that didn't actually update causes them to be re-exported and results in duplicates at my export destination.

The Readwise API docs say:

Finally, we de-dupe highlights by title/author/text/source_url. So if you send a highlight with those 4 things the same (including nulls) then it will do nothing rather than create a "duplicate".

Do you know if the above still updates updated_after?

---

As discussed in this discussion, this isn't anything controlled by October but it is an interesting oversight given that October makes use of the no-op functionality.

That is, the Readwise API is supposed to do nothing if a highlight hasn't changed but it appears to internally update the updated_at field, effectively breaking paging with the export endpoint.

I've raised this with the Readwise developers just now so I'll be posting to this issue with any updates.

[marcus-crane]

I should mention that I raised this with the Readwise team a little while back although I need to check if there is any progress to share