-
Notifications
You must be signed in to change notification settings - Fork 244
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
[SDL-0190] Handle response from HMI during resumption data #3475
[SDL-0190] Handle response from HMI during resumption data #3475
Conversation
Fix RAI default timeout As RAI request does not depend on any HMI response there is no need to track any timeout for it. RAI request will be removed from/ RequestController queue upon RAI response which will be sent anyway Update UT
Update SDL logic to avoid sending of unsubscribeVD to HMI during vehicle data resumption for case when another application is also have pending subscription for the same vehicle data.
Changed SDL logic to update subscription results for each pending subscription request before notifying resumption processor about current subscription is processed. This should be done beforehand because after raising event to processor it can finish resumption process and if it has failed then it can trigger sending of the next subscription request. So at that point, each subscription request should contain updated subscriptions status, otherwise some redundant requests might be sent.
* @brief The ResumptionRequestIDs struct contains fields, needed during | ||
* processing events, related to responses from HMI to each resumption request | ||
*/ | ||
struct ResumptionRequestIDs { |
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.
ResumptionRequestIDs -> ResumptionRequestID
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.
Done in eb41075
return has_subscriptions_to_restore; | ||
} | ||
|
||
bool ResumptionRequestIDs::operator<(const ResumptionRequestIDs& other) const { |
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.
move it upper as util function
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.
Done in eb41075
<< function_id << " correlation id: " << corr_id); | ||
|
||
auto found_app_id = GetAppIdWaitingForResponse(function_id, corr_id); | ||
if (!found_app_id) { |
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.
Add logging that response was not expected
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.
Done in eb41075
Please be informed, we have added two more additional commits (5360321 & cf5b42d), according to UPD: cherry-picked after 'develop' merge commit one more time: |
cf5b42d
to
47832c9
Compare
...ts/application_manager/rpc_plugins/sdl_rpc_plugin/include/sdl_rpc_plugin/sdl_app_extension.h
Outdated
Show resolved
Hide resolved
...ation_manager/rpc_plugins/vehicle_info_plugin/src/vehicle_info_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
@AKalinich-Luxoft We would appreciate if developers did not force push on sdl_core repository to a pr that is in review. It makes it difficult to review a PR because we cannot tell what was changed since the last review. In general, please do not rebase, do not force push against sdl_core. Instead, you can merge the current develop branch into your PR branch. Thank you |
If we are going to include f35e573 in this PR, lets fix the structure of Should be |
@iCollin sorry for that. We will avoid force-pushes in a future during PR review |
I think it is better to update entire structure and align it with the rest of plugins in 0188. In terms of this PR, we can keep this structure simple as it has the only place of usage. |
src/components/application_manager/include/application_manager/display_capabilities_builder.h
Outdated
Show resolved
Hide resolved
src/components/application_manager/src/resumption/resumption_data_processor.cc
Outdated
Show resolved
Hide resolved
...rpc_plugins/app_service_rpc_plugin/test/app_service_plugin/app_service_app_extension_test.cc
Outdated
Show resolved
Hide resolved
...n_manager/rpc_plugins/sdl_rpc_plugin/include/sdl_rpc_plugin/sdl_pending_resumption_handler.h
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
...ponents/application_manager/rpc_plugins/sdl_rpc_plugin/src/sdl_pending_resumption_handler.cc
Outdated
Show resolved
Hide resolved
…mCapabilitiesAppExtension
Fixes #2486
This PR is ready for review.
Risk
This PR makes no API changes.
Testing Plan
Fixes:
Summary
Implemented logic of HMI erroneous responses handling during resumption process
CLA