-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[web] fix rest-test issues #593
base: main
Are you sure you want to change the base?
Changes from all commits
a43127a
7a4769c
50baa34
0e7a66a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -125,10 +125,6 @@ Resource::Resource(ControllerOpenThread *aNcp) | |
mResourceCallbackMap.emplace(OT_REST_RESOURCE_PATH_DIAGNOETIC, &Resource::HandleDiagnosticCallback); | ||
} | ||
|
||
void Resource::Init(void) | ||
{ | ||
} | ||
|
||
void Resource::Handle(Request &aRequest, Response &aResponse) const | ||
{ | ||
std::string url = aRequest.GetUrl(); | ||
|
@@ -519,33 +515,21 @@ void Resource::UpdateDiag(std::string aKey, std::vector<otNetworkDiagTlv> &aDiag | |
|
||
void Resource::Diagnostic(const Request &aRequest, Response &aResponse) const | ||
{ | ||
otbrError error = OTBR_ERROR_NONE; | ||
OT_UNUSED_VARIABLE(aRequest); | ||
|
||
struct otIp6Address rloc16address = *otThreadGetRloc(mInstance); | ||
struct otIp6Address multicastAddress; | ||
|
||
VerifyOrExit(otThreadSendDiagnosticGet(mInstance, &rloc16address, kAllTlvTypes, sizeof(kAllTlvTypes), | ||
&Resource::DiagnosticResponseHandler, | ||
const_cast<Resource *>(this)) == OT_ERROR_NONE, | ||
error = OTBR_ERROR_REST); | ||
VerifyOrExit(otIp6AddressFromString(kMulticastAddrAllRouters, &multicastAddress) == OT_ERROR_NONE, | ||
error = OTBR_ERROR_REST); | ||
VerifyOrExit(otThreadSendDiagnosticGet(mInstance, &multicastAddress, kAllTlvTypes, sizeof(kAllTlvTypes), | ||
&Resource::DiagnosticResponseHandler, | ||
const_cast<Resource *>(this)) == OT_ERROR_NONE, | ||
error = OTBR_ERROR_REST); | ||
SuccessOrExit(otThreadSendDiagnosticGet(mInstance, &rloc16address, kAllTlvTypes, sizeof(kAllTlvTypes), | ||
&Resource::DiagnosticResponseHandler, const_cast<Resource *>(this))); | ||
SuccessOrExit(otIp6AddressFromString(kMulticastAddrAllRouters, &multicastAddress)); | ||
SuccessOrExit(otThreadSendDiagnosticGet(mInstance, &multicastAddress, kAllTlvTypes, sizeof(kAllTlvTypes), | ||
&Resource::DiagnosticResponseHandler, const_cast<Resource *>(this))); | ||
|
||
exit: | ||
|
||
if (error == OTBR_ERROR_NONE) | ||
{ | ||
aResponse.SetStartTime(steady_clock::now()); | ||
aResponse.SetCallback(); | ||
} | ||
else | ||
{ | ||
ErrorHandler(aResponse, HttpStatusCode::kStatusInternalServerError); | ||
} | ||
aResponse.SetStartTime(steady_clock::now()); | ||
aResponse.SetCallback(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't need to address it in this PR: the function name There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, will do it in #537 |
||
} | ||
|
||
void Resource::DiagnosticResponseHandler(otError aError, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, what happens if we fail in this function? Simply ignore the error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that It may fail when node is detached or no buffer for message.
So I think one solution is to define more HTTP status code according to these newly added error code, I think I could do it after #532 is merged.
Another solution is like this, we ignore all errors(more simple, but still reasonable).
For one thing, it could address the
no buffer
problem - although we fail in this API call, if we have diagnostic information(received in 4s but due to another call) left inresource
, this information is still valid and could be sent as response.For another thing, we could just view empty response as "some issues happen, we can't get anything now".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tttttangTH Is this true for your changes? I didn't see why we cannot handle the possible failures in this PR. It looks to me that keeping
should just work. Why did you remove this error handler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because if we call
otThreadSendDiagnosticGet
too many times within a specific period, we will get ano buffer
error for this call( for example, when we send 10 requests fordiagnostics
concurrently , theno buffer
error usually occurs).But actually I prefer not viewing it as an error for HTTP response because the reason for calling
otThreadSendDiagnosticGet
each time when the server received a request fordiagnostics
is to update the information we maintained(we have a hash table to record all the diagnostic information we received within 4 seconds). If we have a 'no buffer' error, it means we have call the API many times recently so information in the hash table is almost the latest.I know the right way to deal with this problem is to make an exception for
no buffer
rather than remove the error handler. I expect to do this after #532 because I think I may need to rewrite error handler of all RESTful API according to the modifications in #532 . So here I just ignore it currently.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is
no buffer error
not good for such situation? I thinkno buffer error
was exactly what happened and should be reflected by the HTTP response.Maybe we can return
507 Insufficient Storage
forno buffer error
.But if the test is sending too much requests and is expecting
no buffer error
to happen sometimes, the test client can conclude with success even if there are some no buffer errors.Thoughts? @tttttangTH @wgtdkp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tttttangTH You should not just remove the error handler. You can at least add a log for this error.
I don't see why we need to wait for #532. Are there any REST feature that depends on #532?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have't found any other feature depend on #532 , but it seems we won't catch
no buffer
atotThreadSetReceiveDiagnosticGetCallback
before #532 is applied.I noticed
no buffer
before when when I wrote this API, at that time,no buffer
was just anInfo
, and I have chosen to ignore it at that time. But It‘s thoughtless for me to just remove the error handler here.