Accidentally stepped on Feign's pit

introduction

A while back, not just use feign called third-party interfaces do "actually hides a comment feign so much knowledge! ” thinks feign quite easy to use, the code is relatively simple to write,
However, readers have also been sprayed that the introduction of a httpClien can solve the problem, it must be so complicated. In fact, the original project used feign to interact with other businesses, so there is no need to make another HttpUtils . Recently, I received another request to continue to access a third-party video verification video. Why do we need to access video verification? For example, if a user passes in a video, we need to verify this video to see if it is compliant, whether it is pornographic or political, etc. If these videos need to be reviewed one by one manually, this is more labor intensive, so we need to access the video verification function of Alibaba Cloud, and this will help us solve the problem of whether this video is compliant. After reading the document, it is relatively easy to connect the parameters, one is the url of the video, and the other is the situation where the video needs to be verified.

Step on the pit

After the background introduction, we can directly connect to it. After three times, five times, and two are connected, the self-tested a few small videos are in line with the normal process, and then the test is proposed.
I tested more than a dozen case and found no problems. Then I followed the next release version and released it for production. I also watched a few videos in production without any problems. Then this function is official
The interaction is complete. However, after a few days, I was found by the operation again, saying that a lot of sudden accumulations, a lot of video audits have failed, I think you will definitely not be able to use it, when you go online, they are all good, it must be your operating posture. . The problem of whispering and digu still needs to be solved.
First, open the log and find that many errors are returned with the same error code, but there are also successful calls. Since it is a third-party error report, it must be a third-party bug. If it is a bug I wrote, it will definitely be a verification failure. There will be no partial success or partial failure, so I picked an error case , Throw the request parameters and the result of the request to a third party to help them find out what the problem is. The most basic things for people to troubleshoot problems still need to provide, such as call time, request parameters, request interface and other information. With this information, others can help you locate the problem more conveniently and quickly. However, in the company, the business side often finds you to troubleshoot the problem directly. @ you directly, call your interface and report an error, so quickly solve it. Don't talk about which environment? Don't talk about which interface? No request parameters are sent. Anyway, there is nothing, it's your problem, just solve it for me as soon as possible. But in this way, I often missed this parameter, or my environment is wrong. Find someone to help you locate the problem. At least the three elements of the problem should be clarified, right? At least you need to check whether it is your problem first, right? This should be the most basic quality of being a programmer! Pulling a long way back to the topic. After all, money is spent. As a third party, the response speed of troubleshooting production problems is still possible, and the problem is located immediately. It turned out that the link to the video I submitted in the past could not be opened, so it could not be verified, so the verification failed. But I can open this video link according to the log recorded by me here. I immediately asked them to send me the parameters they received, and then compare them with the link to my log:

We can see that the difference lies in the last few letters. Friends who know must be able to see the problem at a glance. The URL received by the third party was by 161ad52905de16 decode , and then our own URL can If it is opened, some special characters of this link need to be encoded before it can be opened. If it is directly decode , it cannot be opened. Then find a third-party person to confirm whether they have performed decode on our parameters, and the final conclusion is no. Could it be a problem with our code, I checked the code carefully and found such a line of code that may have an impact

 @PostMapping(value = "xxxx", produces = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
    Response submit(@SpringQueryMap VideoValidationSubmitReq req);

This produces is accessed according to the provided document and it should be no problem.

debugging through POSTMAN 161ad52905de6d, the problem was not reproduced. The problem must be in the process of calling feign no secret under the source code of , after the last pit incident, "feign's comment actually hides so much knowledge!" ” read the source code, this time reading its source code is a bit familiar, and the problem was located quickly in the end. The key code that ultimately locates the problem is this line,

UriUtils.encode

We can enter this method. First look at the comment of this method and we will understand the reason:

If the parameter that needs to be encode encode , it will not continue to be encode , just skip this character. Obviously, some of our parameters above have already been encode , and then after passing through feign , only the parameters that have not been encode will continue to encode , which will cause the third-party server to accept the parameters here. After decode , all the parameters URL passed by me were decrypted. After all decryption, url failed after parsing and could not be opened normally. We find the reasons to solve the problem is relatively simple, since feign used encode not meet our requirements, we will not use its methods to provide, in line quickly resolve bug principles and then produces designated as application/json;charset=UTF-8 ", then the parameters Pass the parameters to the third party by manually calling URLEncoder.encode (xxx,"utf-8")`.
If this method has been encode string will continue to second encode and will not UriUtils.encode experience has been the same encode characters do not directly encode up. After quickly fixing the bug and letting the test help to test it, there is no problem, and quickly release it to production, otherwise the operation staff will keep running. After the code is published, change the state of the video that failed the verification, and then manually trigger job to run it again, and observe that all verification passes for a while. This bug` has finally been fixed. Although the solution is not perfect, we should fix the problem first, and then we will study the more elegant solution later. So we have to quickly explain the reason to the leader? Otherwise, I don’t know if there is a year-end bonus?

Finish

• Due to my lack of knowledge, there will inevitably be mistakes. If you find something wrong, please leave a message to point it out and I will correct it.
• If you think the article is not bad, your forwarding, sharing, admiration, liking, and commenting are your greatest encouragement to me.
• Thank you for reading, welcome and thank you for your attention.