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

บั๊กเรื่องเงินหกจุดในการแยกบิลหลายสกุลเงิน

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

การตรวจสอบเมื่อ 2026-08-21 พบข้อบกพร่องเรื่องสกุลเงินหกจุดที่ชุดทดสอบผ่านมาตลอด โดยต้นเหตุคือประโยคหนึ่งในเอกสารที่เลิกเป็นจริงไปอย่างเงียบ ๆ

ประโยคเก่าหนึ่งประโยคในเอกสารทำให้เกิดบั๊กเรื่องเงินหกจุด การตรวจสอบระบบหลายสกุลเงินของ Dimesum เมื่อ 2026-08-21 พบมันในโค้ดที่ชุดทดสอบของเราผ่านมาตลอด รวมถึงหน้าเคลมที่แสดงหนี้ ¥6,000 ออกมาเป็น -₹60.00 ประโยคนั้นคือ "groups are INR-pinned" ซึ่งเป็นจริงจนถึง W7 กลายเป็นเท็จตั้งแต่วินาทีที่มันปล่อยออกไป และยังคงค้างอยู่ใน FOLLOWUPS.md อีกหนึ่งสัปดาห์ต่อมา

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

รายการ follow-up ที่กลายเป็นจริงแล้วนั้นแย่กว่ารายการที่ยังค้างอยู่

Dimesum พักงานที่เลื่อนออกไปไว้ใน FOLLOWUPS.md หนึ่งแถวต่อหนึ่งการตัดสินใจ พร้อมเหตุผลที่พักมันไว้ รายการ A17 บอกว่ากลุ่มถูกตรึงเป็น INR ว่าการเดินทางไปต่างประเทศไม่สามารถบันทึกในสกุลเงินที่มันเกิดขึ้นได้ และว่าการแก้ไขรอการตัดสินใจของผู้ก่อตั้ง แต่ W7 ก็ปล่อยหลายสกุลเงินออกไปอยู่ดี ค่าใช้จ่ายอาจอยู่ในสกุลเงินใดก็ได้ และยอดคงเหลือถูกผูกด้วย (group_id, member_id, currency) โดย migration ledger/00005 ไม่มีใครขีดฆ่าแถวนั้น

การตรวจสอบครั้งถัดมาอ่าน A17 สรุปว่าส่วนนี้ยังไม่ได้สร้าง และไม่เคยเปิดโค้ดของการชำระ การเคลม หรือหน้าแลนดิงเลย เส้นทางเรื่องเงินที่มองไม่เห็นสกุลเงินสามจุดยังคงถูกปล่อยออกไปเพราะประโยคเดียว ไม่มีปัญหายากอะไรมาขวางเลย docstring ของ app/amount.py ก็มีคำอ้างเดียวกัน ผู้อ่านจึงถูกบอกถึงสองครั้ง

เลข 100 ที่ฮาร์ดโค้ดตัวเดียวกันโผล่มาในสามไฟล์ที่ต่างกัน

เงินในที่นี้คือหน่วยย่อยแบบ int64 บวกกับรหัส ISO 4217 และไม่มี float มาแตะต้อง จำนวนเต็มแม่นยำโดยธรรมชาติ ดังนั้นเลขคณิตที่ยังเสี่ยงเหลืออยู่จึงมีเพียงการแปลงระหว่างหน่วยหลักและหน่วยย่อย หน่วยย่อยไม่ได้เป็นหนึ่งในร้อยเสมอไป JPY ไม่มีเลย KWD มีทศนิยมสามตำแหน่ง และทุกครั้งที่ฮาร์ดโค้ดเลข 100 คือการเดิมพันว่าผู้ใช้อยู่แต่ในประเทศ

ไฟล์ app/amount.py ของ Python sidecar เป็นจุดแรกที่พบ ถูกดึงออกก่อนการตรวจสอบในฐานะกับระเบิดมากกว่าจะเป็นข้อบกพร่องที่ทำงานอยู่ มันคูณตัวเลขใด ๆ ที่อ่านออกมาจากประโยคด้วย 100 ใบเสร็จ ¥1,200 จึงกลายเป็น 120,000 หน่วยย่อย ซึ่งอ่านได้ว่า ¥120,000 บนสกุลเงินที่ไม่มีหน่วยย่อย ค่าคงที่นี้พองบิลของใครบางคนขึ้นร้อยเท่า ตอนนี้ฟังก์ชันจึงไปค้นค่า exponent ของสกุลเงินในคำขอแทน

การตรวจสอบพบค่าคงที่เดียวกันบนหน้าที่ผู้ใช้ตัดสินใจว่าจะยอมรับยอดคงเหลือหรือไม่ formatMinor ที่อยู่เบื้องหลังหน้าเคลม /m/{token} หารด้วย 100 แล้วเอาสัญลักษณ์รูปีมาแปะไว้ข้างหน้า หนี้ ¥6,000 จึงพิมพ์ออกมาเป็น -₹60.00 สัญลักษณ์ผิดและเป็นแค่หนึ่งในร้อยของจำนวนเงิน พี่น้อง JSON ของมันคือ /v1/claims ก็พังไปพร้อมกัน มันยุบแถวต่อสกุลเงินของสมาชิกให้เหลือแถวเดียวและเก็บสกุลเงินที่แมปเขียนทับไว้เป็นตัวสุดท้าย

ไฟล์ที่สามคือ internal/ingestion/store.go ซึ่ง W8 พบขณะขยายการตรวจจับรายการซ้ำ ไม่ใช่จากการตรวจสอบ ค่าความคลาดเคลื่อน "บวกลบหนึ่งรูปี" ของมันคือค่าคงที่ 100 หนึ่งรูปีนับเป็น paise เป็นแถบบวกลบ ¥100 บนสกุลเงินที่ JPY ไม่มีหน่วยย่อยเลย ตอนนี้ทั้งสามไฟล์อ่านค่า exponent แล้ว

การเปรียบเทียบจำนวนเต็มเปล่า ๆ ทำให้เยนดูเหมือนรูปี

ชั้นตรวจจับรายการซ้ำของ Dimesum ตรวจรายการที่จับได้ใหม่เทียบกับค่าใช้จ่ายล่าสุด เพื่อไม่ให้ใบเสร็จที่นำเข้ามาคิดเงินซ้ำกับรายการที่มีคนพิมพ์เองด้วยมือ คิวรีที่อยู่ข้างแถบความคลาดเคลื่อนนั้นไม่มีตัวกรองสกุลเงินเลย ¥1,000 จึงตรงกับ ₹1,000 และการนำเข้าเสนอที่จะแทนที่ค่าใช้จ่ายที่มันไม่มีอะไรเกี่ยวข้องด้วย กลุ่มเป็นหลายสกุลเงินมาตั้งแต่ ledger/00005 เคสนี้จึงเข้าถึงได้จริง ไม่ใช่แค่ในทางทฤษฎี

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

เอนจินสองตัวตอบว่า "ใครจ่ายให้ใคร" และตัวที่สองมองไม่เห็นสกุลเงิน

ข้อบกพร่องที่แพงที่สุดเป็นเชิงโครงสร้าง ไม่ใช่เชิงเลขคณิต เส้นทางเขียนของการชำระวางแผนผ่าน internal/platform/simplify ซึ่งเป็นเอนจิน min-cash-flow ตัวที่สอง โดย struct Balance ของมันไม่มีฟิลด์สกุลเงิน ผลรวมศูนย์ต่อสกุลเงินทำให้ผลรวมแบบแบนเป็นศูนย์ไปด้วย หนี้ ¥300,000 กับหนี้ ₹500 จึงหักล้างกันจนเหลือศูนย์ และไม่มี guard ใดปฏิเสธแผนนั้น จากนั้นแผนจึงจับคู่เจ้าหนี้เยนกับลูกหนี้รูปี

การเขียนทำให้แย่ลงไปอีก บริการประทับ Currency: g.DefaultCurrency ลงบนทุกการชำระ หนี้ ¥300,000 จึงอนุมัติรายการบัญชี INR และหนี้เยนก็ไม่สามารถเคลียร์ได้เลย

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

เพดานเท่ากับศูนย์ถูกอ่านว่าไม่มีเพดาน

guard กันจ่ายเกินปฏิเสธการจ่ายที่มากกว่าหนี้ที่มันชำระ guard นั้นอ่าน outstanding > 0 && amount > outstanding เพดานเท่ากับศูนย์จึงข้ามการเปรียบเทียบไปทั้งหมด คนที่บันทึกการจ่ายเทียบกับหนี้ที่ไม่มีอยู่จริงคือเคสเดียวที่กฎนี้มีไว้เพื่อจัดการ และมันคือเคสที่ผ่านฉลุยไปได้

การแก้คือชนิดข้อมูล ไม่ใช่เงื่อนไข ตอนนี้ OutstandingMinor เป็น *int64 ดังนั้น "ไม่มีใครคำนวณค่านี้" จึงเขียนแบบเดียวกับ "คำตอบคือศูนย์" ไม่ได้ nil ข้ามการตรวจและหมายถึงไม่ทราบค่าจริง ๆ ผู้เรียกใด ๆ ที่เข้าถึงบัญชีได้ส่งตัวเลขจริงเข้ามา

ทำไมชุดทดสอบสีเขียวถึงไม่พิสูจน์อะไรเลย

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

ตัวตรวจสอบบัญชีแบบ end-to-end มีความมองไม่เห็นเดียวกัน ซึ่งเป็นส่วนที่ควรจดจำไว้ ตัวตรวจสอบรวมยอดรายการต่อสมาชิกโดยไม่จัดกลุ่มตามสกุลเงิน มันจึงตีปลาหน้าไซบนกลุ่มสองสกุลเงินที่แข็งแรงดี และรวมได้เป็นศูนย์บนกลุ่มที่พังถึงสองครั้ง false negative คือทิศทางที่อันตราย ตัวตรวจสอบที่สร้างบนสมมติฐานเดียวกับโค้ดย่อมเห็นด้วยกับโค้ดเสมอ