mno tao

One common source of the decomposed form: file names from macOS. HFS+ stored names decomposed, so when an import key is derived from a file or folder name created on a Mac, it can arrive as "Jose\u0301" while the same name typed into a browser form is usually precomposed. Same NFC step fixes it, but it helps to know where the second variant comes from when you go looking. On the length section: if the display-name limit is also checked in the browser, JavaScript's string.length counts UTF-16 units too, so client and server can agree with each other and still disagree with the user. Intl.Segmenter with granularity "grapheme" gives the client the same unit as StringInfo.

Fair point about another acquisition landing between the UPDATE and the read. Logging it as diagnostic evidence with an unknown outcome allowed seems like the honest version, and it keeps the adapter contract to what it can actually guarantee. Thanks for the detailed answer.

One thing worth adding for anyone adopting this: count rejected publications by cause. Zero rows because Generation moved means another worker took over, which is the design working. Zero rows with Generation unchanged means only the lease time ran out, so builds are outliving the lease and its length or renewal needs attention. The UPDATE alone cannot tell the two apart, so a follow-up read of the row is needed to log which one happened. Did you consider returning the reason from the adapter instead of a bool?

Nice approach, and the size table makes the case well. Two things that might be worth a line in the post: The build now needs jsDelivr to be reachable, so committing the generated sprite (or caching the fetched SVGs) keeps CI reproducible when the CDN is slow or blocked. And if the sprite is referenced with , the file has to come from the same origin as the page, because does not load cross-origin files. That one shows up when static assets move to a separate CDN domain.

The note that Deprecation is a Structured Field Date (@1735689600) while Sunset stays an HTTP-date is the detail most write-ups skip, good to see it spelled out. Two related bits from the RFCs that fit the staged plan: RFC 9745 allows the Deprecation date to be in the future, so the header can ship in stage one before the endpoint is formally deprecated, and Sunset can't be earlier than that date. RFC 8594 also registers a separate rel="sunset" link relation, so the retirement policy page and the migration guide (rel="deprecation") can be two different links. On brownouts returning 429: a client with an adaptive rate limiter reads that as "slow down", backs off, succeeds on retry, and nobody notices. A distinct error code in the body, like the one in your middleware, is what makes it show up in the consumer's logs as something other than throttling.