事件起因
這幾天在排查推薦服務線上超時異常時(下篇文章發(fā)出),偶然幫平臺研發(fā)部門發(fā)現(xiàn)了一個Bug。
過程有點曲折直接上重點。

異常信息
{"code":500,"message":"RuntimeException Failed to convert value of type [java.lang.String] to required type [long]; nested exception is java.lang.NumberFormatException: For input string: \"2019-05-0811:39:24.086\"","result":null}。
原因
頁面URL:http://xxx.com/api/xxx/trxxxxInfo?traceId=xxx.xx.xxx.xx-xxxx^1557056xxxxx^2x36xxx×tamp=2019-05-08%2011:39:24.086中,請求參數(shù)timestamp=2019-05-08%2011:39:24.086日期格式中間莫名多出一個%20。
URL里出現(xiàn)%20是因為地址中存在的空格被轉(zhuǎn)碼成了%20導致日期格式轉(zhuǎn)換出錯。
URL編碼表


思考
本身這個Bug很容易被發(fā)現(xiàn),而且問了一個研發(fā)同事也知道該問題,但是沒有排查是什么原因?qū)е碌?,也沒人推動和反饋給平臺研發(fā)部門。 雖然這個Bug對自身業(yè)務沒有影響,可是責任心很重要。。。