Bridgy Fedのブリッジ元でアクティビティを取り消してもPDS（arroba）でレコードが上手く削除されないということがあって、そのときに同じアクティビティを再度実行したところレコードが二重に作られるというということがあったな（このケースでは問い合わせて手動で消してもらった）
このケースではそもそもBridgy Fedレベルで整合性が破綻しているような状態なので、正常な状態においてarrobaがこの手の重複を防がない仕様なのかはこれだけでは何とも言えないだろうけど（コードは未読）
Bridgy Fedとarroba、他にも不整合なレコードを作って素通しするケースがありそうな雰囲気があるし……
QT: https://fedibird.com/@tesaguri/113560911299653260 [参照]
$ curl --fail-with-body -s -H 'Accept: application/json' 'https://atproto.brid.gy/xrpc/com.atproto.repo.listRecords?repo=did:plc:lffon5yhpjy26636i2xjl6as&collection=app.bsky.feed.post' | jq
{
"error": "InvalidRequest",
"message": "in com.atproto.repo.strongRef, string cid with value `''`: is invalid for format cid"
}
$ curl --fail-with-body -s -H 'Accept: application/json' 'https://atproto.brid.gy/xrpc/com.atproto.repo.listRecords?repo=did:plc:lffon5yhpjy26636i2xjl6as&collection=app.bsky.feed.post' | jq
{
"error": "InvalidRequest",
"message": "in com.atproto.repo.strongRef, string cid with value `''`: is invalid for format cid"
}
あとリポジトリ自体が何かの整合性がおかしそうというケースもあるし
QT: https://fedibird.com/@tesaguri/114410127354715218 [参照]
`atproto.brid.gy`、`plc.directory`にすら存在しないDIDに関するレコードを返す例があったりして謎（<https://atproto.brid.gy/xrpc/com.atproto.repo.getRecord?repo=did:plc:rtl7lmwverrqatlni6qnzjr4&collection=app.bsky.actor.profile&rkey=self>）
`atproto.brid.gy`、`plc.directory`にすら存在しないDIDに関するレコードを返す例があったりして謎（<https://atproto.brid.gy/xrpc/com.atproto.repo.getRecord?repo=did:plc:rtl7lmwverrqatlni6qnzjr4&collection=app.bsky.actor.profile&rkey=self>）
Bridgy Fed、割と諸々の整合性が怪しいことが多い。Mastodonでいうところの`delete_arrived_first`のケースがハンドルされていなかったりするらしいし（<https://github.com/snarfed/bridgy-fed/issues/1361>）
（まあそもそもFediverseの諸実装が全体的に何かのアクティビティの配送が失敗したらやり直しが効かなそうな運用で回しているところが多い気がするけど）
確かに……と思ったけど、この例は`atproto.brid.gy`に対する`com.atproto.repo.describeRepo`でも見つからないのだよな（<https://atproto.brid.gy/xrpc/com.atproto.repo.describeRepo?repo=did:plc:rtl7lmwverrqatlni6qnzjr4>）。`describeRepo`はdeactivatedなリポジトリについては404を返すとかだっけ？
