fix: use warn log for get healthcheck target status failure#10156
Conversation
|
The error log occurs when the upstream is rebuilt as we add or delete an upstream node. The state is not correct, it will lead to unbalanced load. It's a problem, we should fix this, so the error log level is appropriate here. |
|
APISIX use pre-defined preprocessor to handle the default |
|
@shreemaan-abhishek If @leslie-tsang's suggestion satisfy your requirement, the pr could be closed? |
|
@monkeyDluffy6017, although the background for this PR was writing a test case, I am still convinced that using an error level log leads to a false negative. |
|
@shreemaan-abhishek I have fix this by the following pr, so the error log won't happen again: |
|
By the way, the log level |
|
I will close this pr, feel free to reopen it |
we also meet this error log, #9415, finally we decide to ignore this target not find error, treat the node as health btw it may not lead to unbalanced load, because it add all node to the up_nodes as default. |
|
I reopened this pull request because many people have encountered the same issue. This error should only occur when multiple requests are made concurrently while creating or modifying an upstream. While the first request is in the process of creating a health check object, the second request encounters this error because it cannot access the object that hasn't been created yet. However, this error does not actually impact request forwarding. Lowering the error log level from 'error' to 'warn' is reasonable to prevent any misunderstanding. |

Description
apisix/apisix/balancer.lua
Lines 82 to 83 in 35349ef
The above error log reports an error in some cases even if the request is valid and successful. In the initial requests,
get_target_status()will always fail as the target status is not yet finalized. It does not make sense to report an error for positive outcomes.Note that the
get_target_status()failure just signifies that the system failed to get the health status only. We do not know if the target is actually unhealthy. And even if the node is unavailable/unhealthyget_target_status()does not report the error, but some warn logs like this:Background information:
I encountered this problem while writing a test case for
httpsbased healthcheck.Checklist