v0.4.3

FeatherReader 0.4.3 fixes two problems on the path that writes to your PDS. They apply on any PDS, and were found while evaluating vlpds. The README is also rewritten for 0.4.x.

Full engineering detail is in CHANGELOG.md.

Upgrade notes

• No schema change and no new settings. Upgrading from 0.4.2 is a deploy, and rolling back to 0.4.2 is a redeploy. Both were rehearsed on a fork of a production volume: 0.4.3 booted with db: ok, and 0.4.2 then booted on the result, also with db: ok.
• What to expect after deploying:
  • A reader whose read-state sync was already stuck recovers on the next flush, after one readState listing.
  • An OPML import of more than 200 feeds now succeeds, or reports how many feeds were saved.
• deploy/upgrade-from is now 0.4.2, so the upgrade-boot gate tests from it.

Fixed

• applyWrites is sent in calls the PDS accepts (#242, closes #240).
  • The limits: the reference PDS refuses more than 200 writes in one call, and older releases refuse request bodies over 150 KiB.
  • What broke before: an OPML import put every feed in one call, up to 500, and a read-state flush put every dirty feed in one call. Both could fail outright.
  • Now: writes go out in order, in calls of at most 200 writes and 128 KiB, stopping at the first failure. A partial failure reports how many writes landed.
• A read-state flush that disagreed with the PDS no longer fails forever (#243, closes #241).
  • The cause: the flusher chose between create and update from a local flag. If a record existed when the flag said it didn't, every flush for that reader failed. That happened after a lost success response or a fresh local database. The reverse case, a record deleted elsewhere, failed the same way.
  • Now: it lists the reader's readState records once, corrects the flags, and retries once. It never loops.
  • Split flushes: if a split flush fails partway, the writes that did land are recorded, so nothing after them gets stuck.

Docs

• The README describes 0.4.x (#244, #245). It covers standard.site publications, the real OAuth backend in production, the invite-only beta, the release pipeline, and four architecture diagrams. The diagrams are shown as light/dark images so they display in the GitHub mobile app and on crates.io.

Known

• #246: a fresh or restored local database overwrites the reader's existing readState records on their PDS instead of merging them. This predates 0.4.3. #243's recovery path reaches this overwrite where it used to get stuck.