v0.7.0

The release that says what to watch in order to claim the promise is being kept. The
promise is a single one — a name you handed out never points at something else and never
stops resolving — so the monitoring is derived backwards from it.

One discarded signal was picked up. Minting has always counted its collisions, and
every caller threw the count away. It is the only sign that the namespace is quietly
filling up, so it is now recorded when it happens.

Replication lag is written up as a correctness problem, not a performance one. If an
ARK answers 404 right after it was handed out, "wait a moment" is not an answer.

Added

• Minting collisions are now recorded (mint_collision).

  mint() has always counted collisions and returned the count, and its docstring said
  the point was to catch a namespace quietly filling up. But all three call sites
  threw it away with ark, _ = — counted, and nobody receiving it.

  One collision does no harm (it retries and succeeds), but a rising rate is the signal
  to add digits, and nobody notices that unless someone is looking. Nothing is logged
  when there are no collisions — a line per mint and people stop reading the log.

• A monitoring design in
  Deployment. What to watch follows
  from what was promised, so the table is derived backwards from the signs that the
  promise is starting to break.

  Replication lag is written up as a correctness problem, not a performance one. With
  minting on the primary and resolution from a replica, an ARK resolved right after it
  was handed out can answer 404 — in most systems that is "wait a moment", but here
  the person concludes the identifier does not exist.

  No metrics endpoint. You already have somewhere logs go, and one pipeline is better
  than two.

---

日本語の変更履歴
· Full Changelog: v0.6.0...v0.7.0