หน้าแรก / บล็อก / เงิน

ทำไมการแก้ไขค่าใช้จ่ายร่วมต้องระบุการแบ่งใหม่

29 สิงหาคม 2569 · อ่าน 5 นาที · Dimesum Engineering

ค่าเริ่มต้นของการแก้ไขคือบั๊กเรื่องเงิน Dimesum จึงบังคับ participants และ split_type ในทุก PATCH ของค่าใช้จ่าย พร้อม base_version ที่ปฏิเสธการแก้ไขที่ล้าสมัยแทนที่จะรวมมัน

การแก้คำผิดไม่ควรเปลี่ยนว่าใครเป็นหนี้ใคร ใน Dimesum การแก้ไขค่าใช้จ่ายร่วมจะระบุการแบ่งทั้งหมดใหม่ participants และ split_type จำเป็นต้องมีในทุก PATCH และการแก้ไขที่ขาดฟิลด์ใดฟิลด์หนึ่งจะได้ 400 กลับมาแทนที่จะเติมค่าเริ่มต้นให้ ค่าเริ่มต้นตอนสร้างคือสมาชิกปัจจุบันทุกคนและการแบ่งเท่ากัน ซึ่งเมื่อใช้กับการแก้ไขแล้วกลายเป็นบั๊กเรื่องเงิน

ความล้มเหลวสองกรณีทำให้เห็นภาพชัด เพื่อนร่วมห้องที่เพิ่งย้ายเข้ามาในเดือนสิงหาคมถูกดึงเข้าไปในมื้อค่ำของเดือนกรกฎาคม เพราะ "สมาชิกปัจจุบันทุกคน" ถูกประเมินตอนที่การแก้ไขเข้ามา ไม่ใช่ตอนที่บันทึกค่าใช้จ่าย การแบ่งค่าเช่าแบบตั้งใจ 70/30 ถูกทำให้แบนเป็น 50/50 เพราะการไม่มี split_type หมายถึง EQUAL ทั้งสองกรณีไม่มีการแจ้งข้อผิดพลาด และทั้งคู่ย้ายเงินจริง

ค่าเริ่มต้นตอนสร้างอธิบายค่าใช้จ่ายใหม่ ไม่ใช่ค่าใช้จ่ายเก่า

ตอนสร้าง ค่าเริ่มต้นนั้นตรงไปตรงมา ผู้บันทึกกำลังดูกลุ่มตามที่เป็นอยู่ และการแบ่งเท่ากันให้ทุกคนคือกรณีที่พบบ่อย Dimesum จึงเติมทั้งสองให้ ค่าใช้จ่ายจะเก็บอินพุตของมันไว้ ไม่ใช่แค่ผลลัพธ์ splits.percent_bp splits.weight และ splits.exact_minor เก็บสิ่งที่ผู้ใช้พิมพ์ ดังนั้นการแก้ไขในภายหลังจึงเปิดมันขึ้นมาใหม่ได้

การแก้ไขเป็นการกระทำอีกแบบหนึ่ง ค่าใช้จ่ายเดียวกันอาจถูกแก้หลายสัปดาห์ต่อมา หลังจากเพื่อนร่วมห้องใหม่ย้ายเข้ามาหรือมีการอ้างสิทธิ์สมาชิกที่ยังไม่ได้ระบุตัว สมาชิกภาพเป็นเป้าหมายที่เคลื่อนที่ แต่การแบ่งไม่ใช่ การนำค่าเริ่มต้นตอนสร้างกลับมาใช้เป็นการขอให้กลุ่มวันนี้ตอบคำถามที่ค่าใช้จ่ายเก่าได้ตอบไปแล้ว

การปฏิเสธที่จะเดาไม่ใช่เรื่องใหม่ที่นี่ ค่าใช้จ่ายที่มีผู้จ่ายหลายคนก็ต้องระบุผู้จ่ายใหม่เช่นกัน soleStoredPayer นำผู้จ่ายที่เก็บไว้กลับมาใช้เฉพาะเมื่อค่าใช้จ่ายมีผู้จ่ายเพียงคนเดียว ดังนั้นการแก้ไขที่เงียบเรื่องผู้จ่ายสองคนจะถูกปฏิเสธแทนที่จะถูกกำหนดใหม่ การแก้ไขที่ไม่พูดถึงผู้จ่ายจะคงผู้จ่ายเดิมของค่าใช้จ่ายไว้ ไม่ใช่คนที่กำลังทำการแก้ไข

API ปฏิเสธการแก้ไขที่ไม่ระบุการแบ่งใหม่

การตรวจสอบที่เกตเวย์ทำงานก่อนการคำนวณเงินใด ๆ เมื่อ participants ว่างเปล่าหรือ split_type ไม่มีค่า คำขอจะได้ 400 กลับมาพร้อมโค้ด invalid_expense และข้อความ "an edit must restate the split: participants and split_type are required" บริการค่าใช้จ่ายย้ำกฎเดียวกันใน validateAmend ดังนั้นผู้เรียกที่เข้าถึงบริการด้วยวิธีอื่นก็จะพบการปฏิเสธเดียวกัน

สกุลเงินอยู่ในตระกูลเดียวกันของการปฏิเสธ การแก้ไขไม่สามารถเปลี่ยนสกุลเงินของค่าใช้จ่ายได้ เพราะแถวยอดคงเหลือเก็บหนึ่งสกุลเงินต่อสมาชิกหนึ่งคน ฝั่งเขียนจะปฏิเสธการเปลี่ยนแปลง และบัญชีแยกประเภทแบบเพิ่มอย่างเดียวจะพักการแก้ไขเช่นนั้นไว้หากมันไปถึง การปฏิเสธตั้งแต่หน้าประตูช่วยไม่ให้สองส่วนขัดแย้งกัน

การแก้ไขที่ล้าสมัยถูกปฏิเสธคืนให้ผู้บันทึก ไม่มีการรวม

base_version คืออีกครึ่งหนึ่งของสัญญา ทุก PATCH พกเวอร์ชันที่ผู้บันทึกอ่านมา และ checkTransition เทียบมันกับแถวที่ทรานแซกชันเพิ่งล็อก ถ้าเท่ากัน การแก้ไขจะมีผลที่เวอร์ชันบวกหนึ่ง ถ้าต่างกัน ผู้เรียกจะได้ HTTP 409 พร้อมโค้ด stale_version

การรวมเป็นทางเลือกที่ชวนให้ทำ และมันผิด การแก้ไขสองครั้งต่อค่าใช้จ่ายเดียวคือคำแถลงที่สมบูรณ์สองชุดว่าบิลนี้หมายถึงอะไร การรวมมันจะได้คำแถลงชุดที่สามที่ไม่มีใครเขียน พร้อมส่วนแบ่งที่ผู้บันทึกทั้งสองคนก็จำไม่ได้ การปฏิเสธส่งข้อขัดแย้งกลับไปให้คนคนเดียวที่แก้ไขมันได้

Idempotency และ concurrency ถูกแยกออกจากกันอย่างตั้งใจ การแทรก revision ทำงานก่อนการตรวจเวอร์ชัน เพราะการแก้ไขที่ลองใหม่พก base version ที่มันอ่านมาแต่แรก ซึ่งตอนนี้ล้าสมัยแล้ว การเล่นซ้ำต้องถูกอ่านว่าเป็นการเล่นซ้ำ ไม่ใช่ข้อขัดแย้ง ดังนั้น revision_id จึงตอบก่อนและคืนผลลัพธ์ที่เก็บไว้

การตอบกลับมีข้อมูลที่การแก้ไขครั้งถัดไปต้องใช้อยู่แล้ว

การบังคับฟิลด์เพิ่มบน PATCH จะยุติธรรมก็ต่อเมื่อไคลเอนต์ได้มันมาอย่างง่าย ทุกการตอบกลับของค่าใช้จ่ายพก version ดังนั้นไคลเอนต์ที่เพิ่งเขียนค่าใช้จ่ายจึงแก้ไขได้โดยไม่ต้องอ่านครั้งที่สอง การตอบกลับของการสร้าง การตอบกลับของการแก้ไข และทุกแถวในรายการ พกฟิลด์เดียวกัน

สำหรับไคลเอนต์ที่ไม่ได้เพิ่งเขียนค่าใช้จ่าย GET /v1/groups/{id}/expenses/{id} จะคืนเวอร์ชัน ส่วนแบ่งที่คำนวณแล้ว และอินพุตที่อยู่เบื้องหลัง อินพุตกลับมาภายใต้ชื่อเดียวกับที่ PATCH รับ ได้แก่ participants split_type percents weights shares items pools ไคลเอนต์อ่านรูปแบบเดียวแล้วส่งกลับพร้อมการแก้ไข แทนที่จะต้องแปลระหว่างสองศัพท์สำหรับบิลเดียว

ความสมมาตรสำคัญที่สุดสำหรับการแบ่งที่สร้างใหม่ไม่ได้ การแบ่งแบบ PERCENT หรือบิลที่แจกแจงรายการไม่สามารถระบุใหม่จากส่วนแบ่งที่คำนวณแล้วเพียงอย่างเดียว เพราะได้ปัดเศษไปแล้วและ basis points กับรายการย่อยหายไปแล้ว สแนปช็อตของ revision พกอินพุตไว้ด้วย ดังนั้นแผ่นประวัติจึงแสดงได้ว่ามีอะไรถูกแจกแจงในเวอร์ชันก่อนหน้าใด ๆ

บังคับตั้งแต่ตอนนี้ เพราะข้อบังคับไม่สามารถเพิ่มภายหลังได้

การบังคับฟิลด์ตั้งแต่วันแรกคือการตัดสินใจเกี่ยวกับอนาคต ไม่ใช่เกี่ยวกับวันนี้ การผ่อนคลายฟิลด์ที่บังคับในภายหลังนั้นเข้ากันได้ย้อนหลัง ไคลเอนต์ส่งมันอยู่แล้ว และเซิร์ฟเวอร์ก็เริ่มรับคำขอที่ไม่มีมัน การเพิ่มข้อบังคับในภายหลังจะทำให้ไคลเอนต์ทุกตัวที่พึ่งพาค่าเริ่มต้นเก่าพัง

ดังนั้นทิศทางจึงถูกเลือกครั้งเดียวตั้งแต่เนิ่น ๆ Dimesum บังคับ participants split_type และ base_version บนการแก้ไข ในขณะที่จำนวนไคลเอนต์ยังน้อยพอที่จะเปลี่ยนได้ หากพบค่าเริ่มต้นที่ปลอดภัยสำหรับการแก้ไขเมื่อใด ฟิลด์เหล่านั้นก็จะกลายเป็นไม่บังคับ และไม่มีสิ่งที่ปล่อยออกไปแล้วหยุดทำงาน