Delete guest user when SetYearDaySchedule is failed

[HunsupJung]

Type of Change

• WWST Certification Request
  • If this is your first time contributing code:
    • I have reviewed the README.md file
    • I have reviewed the CODE_OF_CONDUCT.md file
    • I have signed the CLA
  • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
• Bug fix
• New feature
• Refactor

Checklist

• I have performed a self-review of my code
• I have commented my code in hard-to-understand areas
• I have verified my changes by testing with a device or have communicated a plan for testing
• I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

Summary of Completed Tests

[github-actions]

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/gpjGkvEbzvj4

[github-actions]

Test Results

   72 files    502 suites   0s ⏱️
2 765 tests 2 765 ✅ 0 💤 0 ❌
4 663 runs  4 663 ✅ 0 💤 0 ❌

Results for commit 2c02717.

♻️ This comment has been updated with latest results.

[github-actions]

File	Coverage
All files	81%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lazy_load_subdriver.lua	57%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/init.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lock_utils.lua	68%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua	79%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/can_handle.lua	90%	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 2c02717

[hcarter-775]

In the case this fails, what is the expected result?

Given the current logic, a failure would mean that

1. lockCredentials commandResult is never emitted (HIGH importance)
2. lockUsers commandResult for defaultSchedules will be emitted below, which will fail (MEDIUM importance)

Should we retry the ClearUser command again? If so, how many times?

Also, if it fails after some number of retries, I think we should emit a success result for lockCredentials. What do you think?

[HunsupJung]

lockCredentials commandResult is never emitted (HIGH importance)
lockUsers commandResult for defaultSchedules will be emitted below, which will fail (MEDIUM importance)

I don't understand what you said. The logic up to here is as follows.

1. Plugin sends setCredential for guest
2. Hub sends SetCredential to Door Lock
3. Door Lock creates a user and set the credential
4. Door Lock returns a success result
5. Hub sends SetYearDaySchedule for guest
6. Door Lock returns a failure result
7. Hub sends ClearUser to Door Lock
8. Door Lock clear the user and return a success result
9. Hub set the commandResult of lockCredentials to failure

There is no additional action. I don't think it's the right way to continue follow-up on failures. And now we are putting the default schedule directly from the driver for guest, but I will discuss with Plugin and ask Plugin to put the default schedule on its own. (It is dangerous for the driver to put the schedule on device because the schedule operation may vary from device to device.)

[ctowns]

@HunsupJung could you also fill out the Summary of Completed Tests section on the top PR comment?

[ctowns]

I think this handling that is specific to the defaultSchedule command could benefit from a short comment that explains why this is needed to improve readability.

[HunsupJung]

Okay, I will add the comment.