RTK Queryでretry: 3 が指定されているが、backendがtransactionを考慮していないと挙動がおかしくなる

[hrk091]

RTK Queryのretryが組み込まれ、500番台のエラーのときはauto retryする仕組みとなっているが、backend側がtransactionalなAPIになっておらず、かつ500を返したりする場合に、おかしなバグにつながる。

具体例を以下にあげる。
POST chatの際に、backendはRDBに書き込む -> Amazon SQSに突っ込む -> backendでhookしてwebsocketでUIに通知する、という流れになっているように見えるが、ここでSQSに投入する際に失敗するとUIに500 errorを返している。このAPI設計でUI側でretryを具備すると、SQSとの接続がおかしいときは3回書き込んでしまい、同じchat messageが3つ保存されてしまう事態になる。

このケースは、backend側を 先にSQSに書く -> RDBに書く という形で修正すればよい話だが、他にも類似の問題があるかもしれないので、そもそもUIからauto retryする必要があるのかを検討したい。
（mutationは1回のみ、queryは複数回retryというのが妥当な線かも。できるのかは知らないけど）