事件起因
这几天在排查推荐服务线上超时异常时(下篇文章发出),偶然帮平台研发部门发现了一个Bug。
过程有点曲折直接上重点。
![](https://img.haomeiwen.com/i7260028/d67c99cb06429671.png)
异常信息
{"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中,请求参数timestamp=2019-05-08%2011:39:24.086
日期格式中间莫名多出一个%20
。
URL里出现%20
是因为地址中存在的空格被转码成了%20
导致日期格式转换出错。
URL编码表
![](https://img.haomeiwen.com/i7260028/eb3469c109f1699a.png)
![](https://img.haomeiwen.com/i7260028/476c7d70099ca0e9.png)
思考
本身这个Bug很容易被发现,而且问了一个研发同事也知道该问题,但是没有排查是什么原因导致的,也没人推动和反馈给平台研发部门。 虽然这个Bug对自身业务没有影响,可是责任心很重要。。。
网友评论