[SDLOPEN] RegisterAppInterface: SDL returns DISALLOWED instead of DUPLICATE_NAME

istoimenova commented 7 years ago

Description:

SDL returns DISALLOWED instead of DUPLICATE_NAME when second app is trying to be registered with the same name and id as the first application.

Preconditions:

SDL and HMI are running.
Mobile App is registered to SDL with appName=1, appID=1

Steps to reproduce:

Case1: Try to register new app with the same: appName=1 and appID=1 Case2: Try to register new app with the same: appName=2 and appID=1

Actual result:

App is not registered, SDL returns DISALLOWED response

Expected result:

App is not registered, SDL returns DUPLICATE_NAME response

Environment:

SDL repo: https://github.com/smartdevicelink/sdl_core/tree/feature/extended_policy_functionality SDL commit: 7bd5326 OS with SDL: Ubuntu 14.04 VM used for OS with SDL (yes/no): no ATF version: aa5beae6ab1726a9b43ed2fa15f66c20d7f7883f Transport: WiFi

Attachments

[Uploading SmartDeviceLinkCore.log.zip…]()

Links:

Problem can be reproduced with script: [Uploading RAI_DUPLICATE_NAME.txt…]() [Uploading RAI_DUPLICATE_NAME_Case2.txt…]() Requirements: [RegisterAppInterface] Validation order for appName and appID [RegisterAppInterface] Validation of same "appName" and the same "appID"

Expected delivery

[ ] Source code updates
[ ] Code comments
[ ] UTs add/update
[ ] ATF tests add/update
[ ] Manual tests
[ ] Add/update CI plans/jobs
[ ] SDD updates
[ ] Guidelines update (sdl_core_guides)
[ ] Guidelines update (sdl_hmi_integration_guidelines)

HSavynetska commented 6 years ago

Environment: Script: https://github.com/smartdevicelink/sdl_atf_test_scripts/pull/1944 SDL build: develop branch ( ac8b1c5) ATF: develop branch

Status: Current actual result differs from described from described in defect

Actual result: App is not registered, SDL returns APPLICATION_REGISTERED_ALREADY response

ghost commented 6 years ago

The next pull request provided bug fixing of this issue: #2402

E-SAITO-TMC commented 4 years ago

@joeygrover -san A fix has been proposed for this issue. Is the review of a fix finished? If so, when will it be merged? For the next HU development of TOYOTA, it is necessary to improve the quality of SDLCore, so we believe it is necessary to fix this issue.

theresalech commented 4 years ago

Hi @E-SAITO-TMC, contents for SDL releases are determined by the Steering Committee, and the Project Maintainer works on features and bug fixes raised as high priority by Steering Committee representatives. This particular issue has not yet been raised as high priority. However, if Toyota would like to see this fix in the next release of SDL Core (planned for October 28, 2020), we can make note of such.

Please confirm if this is priority for Toyota. If so, we will include this issue in our proposed release contents, which will be presented to the Steering Committee and voted upon/finalized in June. Thank you!

E-SAITO-TMC commented 4 years ago

@theresalech -san Thank you for your comment. This issue is medium-priority for Toyota.

theresalech commented 4 years ago

@E-SAITO-TMC, thank you. We have documented that this is medium priority for Toyota, and will include for Steering Committee review and vote when planning the contents for the Q4 Core release. This planning will take place in June.

iCollin commented 4 years ago

@E-SAITO-TMC Hello, I find that this issue was fixed when implementing same app multiple devices. To be sure, I created an ATF test with the reproduction steps of this issue. I see this test passing against release 6.1.1 as well as the current develop.

If you are still seeing this issue please let me know.

smartdevicelink / sdl_core