ホーム / ブログ / お金

共有費用を編集するときに分担をやり直す理由

2026年8月29日 · 読了 約5分 · Dimesum Engineering

編集時のデフォルトは金額の不具合になり得るため、Dimesum はすべての費用 PATCH で participants と split_type を必須にし、あわせて base_version が古い編集をマージせず却下します。

誤字の修正が、誰がいくら負担するかを変えてはいけません。Dimesum では、共有費用を編集すると分担全体をやり直します。participants と split_type はすべての PATCH で必須で、どちらかを省いた編集はデフォルトで補われるのではなく 400 が返ります。作成時のデフォルトは現在の全メンバーと均等割りで、編集ではこれらが金額の不具合になります。

2つの失敗が、これを具体的に示します。8月に参加した同居人が7月の食事に引き込まれます。「現在の全メンバー」は費用を書いたときではなく、編集が届いたときに評価されるからです。意図した 70/30 の家賃の分担が 50/50 に均されます。split_type が無いと EQUAL を意味するからです。どちらの失敗もエラーを出さず、いずれも実際のお金を動かします。

作成時のデフォルトは新しい費用を表し、古い費用は表さない

作成時にはデフォルトは正直です。作成者は現状のグループを見ており、全員での均等割りが一般的なケースなので、Dimesum は両方を補います。費用は結果だけでなく入力を保存します。splits.percent_bp、splits.weight、splits.exact_minor がユーザーの入力した内容を保持するので、後の編集で再び開けます。

編集は別の行為です。同じ費用は数週間後、新しい同居人が参加したり、ゴーストメンバーが引き受けられたりした後に訂正されることがあります。メンバー構成は動く的で、分担はそうではありません。作成時のデフォルトを使い回すことは、古い費用がすでに答えた問いを、いまのグループに答えさせることになります。

推測を拒むのは、ここが初めてではありません。複数支払者の費用は、その支払者もやり直す必要があります。soleStoredPayer は費用の支払者がちょうど1人のときだけ保存済みの支払者を再利用するので、2人の支払者について黙ったままの編集は、割り当て直されるのではなく却下されます。支払者について何も言わない編集は、その費用自身の支払者を保ち、編集している人を支払者にはしません。

API は分担をやり直さない編集を却下する

ゲートウェイのチェックは、金額が計算される前に走ります。participants が空か split_type が空白のとき、リクエストはコード invalid_expense とメッセージ「an edit must restate the split: participants and split_type are required」とともに 400 で返ります。費用サービスは validateAmend で同じルールを繰り返すので、別の経路でサービスに到達した呼び出し元も同じ却下に出会います。

通貨も同じ却下の一族に属します。編集は費用の通貨を付け替えられません。残高の行はメンバーごとに1通貨を保持するからです。書き込み側がその変更を却下し、追記専用の台帳は、万一そこに届いてもそのような修正を留め置きます。入口で拒むことで、2つの側が食い違わないようにします。

古い編集は作成者に差し戻され、決してマージされない

base_version は契約のもう半分です。すべての PATCH は作成者が読んだバージョンを持ち、checkTransition がそれをトランザクションがちょうどロックした行と比較します。等しければ、編集はバージョンに1を足して適用されます。異なれば、呼び出し元はコード stale_version とともに HTTP 409 を受け取ります。

マージは魅力的な代替案ですが、間違いです。1つの費用への2つの編集は、その請求が何を意味するかについての2つの完全な表明です。それらをマージすると、誰も書いていない3つ目の表明ができ、どちらの作成者も見覚えのない取り分になります。却下は、その対立を解決できる唯一の人に差し戻します。

冪等性と並行性は意図的に分けられています。リビジョンの挿入はバージョンチェックの前に走ります。再試行された編集は最初に読んだベースバージョンを持っており、それはいまや古いからです。再送は対立ではなく再送として読まれる必要があるので、revision_id が先に答え、保存済みの結果を返します。

レスポンスは次の編集に必要なものをすでに持っている

PATCH でより多くのフィールドを要求するのは、クライアントがそれらを安く得られる場合にだけ公正です。すべての費用レスポンスは version を持つので、費用を書いたばかりのクライアントは2度目の読み取りなしに編集できます。作成レスポンス、修正レスポンス、そしてすべての一覧の行が同じフィールドを持ちます。

費用を書いたばかりではないクライアントには、GET /v1/groups/{id}/expenses/{id} がバージョン、計算された取り分、そしてその背後の入力を返します。入力は PATCH が受け付けるのと同じ名前で返ります。participants、split_type、percents、weights、shares、items、pools です。クライアントは1つの形を読み、編集を加えて投稿し直します。1つの請求について2つの語彙を訳し分けることはありません。

この対称性が最も効くのは、再構成できない分担です。PERCENT の分担や品目ごとの請求は、解決済みの取り分だけからはやり直せません。丸めがすでに適用され、ベーシスポイントと明細行が失われているからです。リビジョンのスナップショットは入力も持つので、履歴シートは過去のどのバージョンで何が品目化されていたかを示せます。

後から要件は足せないので、いま必須にする

初日にフィールドを必須にするのは、今日についてではなく将来についての決定です。必須のフィールドを後から緩めるのは後方互換です。クライアントはすでにそれを送っており、サーバーはそれなしのリクエストを受け付け始めます。要件を後から足すことは、古いデフォルトに頼っていたすべてのクライアントを壊します。

だから方向は一度、早い段階で選ばれます。Dimesum は、クライアント数がまだ変更できるほど小さいうちに、編集で participants、split_type、base_version を必須にします。編集にとって安全なデフォルトがいつか見つかれば、これらのフィールドは任意になり、すでに出荷されたものは何も動かなくなりません。