今天的事件
發生在訂單系統
建立訂閱制的合約時
顯示參數Format Error
BaseContractSn的值為0

奇怪的是支付系統的API
Log顯示有帶入值
然而合約系統卻說值小於等於0

原本以為是錯誤訊息複製貼上沒改到
A欄位為空，卻顯示B欄位沒值
暴力搜尋了一下專案
這個錯誤訊息
還真的是BaseContractSn小於等於0

因為是Http Post
nginx log、IIS log都不會記錄body內容
只好在controller第一行
把參數用log記錄下來
上到Pre環境測試一次

接著就是打開Postman
根據支付系統的參數
再打一次合約系統的API

果不其然
又顯示BaseContractSn為空
查看剛剛埋的Log
其他參數都正常
唯獨BaseContract顯示0
但Postman是有帶入值的

想到這個月是農曆鬼月
不由得背脊發涼
公司普渡我也有參加
不應該有問題才對

看了一下最近的git改動
也和這個API無關
但出現了一個熟悉的關鍵字
BaseContractSn
不過是加在另一個物件上面

這時我才回頭去看Controller的Request物件
BaseContractSn這個欄位
跳綠色小毛毛蟲警告
會隱藏繼承的成員，請使用new關鍵字
format-error-1.png

再看一下繼承關係
父類別的BaseContractSn是int?
子類別的BaseContractSn是int

這次的改動是父類別
沒有發現子類別已經宣告過相同的欄位
所以就炸開了

解決方式也很簡單
確認父類別的欄位可以改為int
就把子類別的欄位砍掉即可

後記
為了寫這篇網誌
嘗試在自己家的電腦重現這個Bug
沒想到卻是困難重重
不管是.net framework或是.net core
request接收到的
都會是子類別的型別
format-error-3.png
format-error-4.png

推測是公司自己刻了底層框架
在reflection的時候做了特殊處理
才會和一般的框架結果不一樣

簡單來說
就是要各種天時地利人和
才能觸發這個Bug

下回預告
開發一個新功能
只有開發者的電腦不work
其他人都正常
難得一見的反工程師Bug

下一回
MenuBar消失 Bug事件