the update hook tears writes
praschke opened this issue · comments
If multiple chapter insertions or edits occur between two uses of FFF, and the newest update occurs later in the chapter list than earlier updates, hookForUpdates discards only the chapter indices after the newest update.
1 2 3 4
1 5 2 6 3 4
would result in
1 2 3 6 3 4
5 has been dropped, and 3 has been duplicated.
The correct index to start discarding from is the oldest chapter after the last use of FFF the chapter earliest in the list with a date after the last use of FFF, but that information is not given to the adapter.
Depends on the site. do_update_hook is only implemented for FimF and OTW sites(ie AO3), and it's basically deprecated for OTW sites since 2015. So I assume you're asking about a FimF story.
Story URL?
Fimfiction chapter URLs include the chapter title and index, so I believe chapters shifted in index by insertion or deletion are handled by the old chapter map similarly to AO3. In this case only in-place edits to chapters earlier in the list than the latest update would be missed.
Syosetu has only sequential indices in the URL, so the old chapter map would not be able to clean up after insertions or deletions. In this case you would get dropped or duplicated chapters with the described behavior, 'discard indices from the latest update'.
I see now that the update hook is called after the old chapter map is given to the adapter, but the only old metadata always accessible in the update hook (the log page is optional) is chapter's title, URL, and body text. But I also see now that the update hook is not always run, so access to the old chapter map doesn't have much point to me.
The only way I can see to correctly pick up updated chapters from syosetu is to give FFF chapter URLs modified to act as a unique key, by appending a query string constructed from the chapter title, publication date, and edit date.
This is a known limitation. If authors change the text of existing chapters, there's no way for FFF to know that in most cases. It's a relatively rare corner case, for what I've seen.
The answer, generally, is to overwrite instead of update in those cases. That's really the only solution that can address the problem for all sites.
I'm closing this since it isn't an issue with the software so much as a discussion of a future possible adapter.