Show lock deletion tip when core update fails with lock error

[Copilot]

• Explore the repository structure and understand the codebase
• Understand where the "Another update is currently in progress" error occurs
• Create a plan for implementing the feature
• Modify Core_Command.php to detect the specific error and show the helpful tip
• Add test case for the new behavior
• Refactor code based on code review feedback (extract helper method and constant)
• Address additional feedback: improve constant naming and message formatting
• Address PR feedback: remove constant and use inline text
• Update test to verify complete error message
• Remove redundant is_wp_error check
• Final verification

Summary

Successfully implemented the feature to show a helpful tip when wp core update encounters the "Another update is currently in progress" error.

Changes Made:

1. Added helper method is_lock_error() - Checks if a WP_Error is related to the core_updater.lock by:
   • Checking for the 'locked' error code (used by WordPress Core)
   • Fallback check for "another update is currently in progress" in the error message
2. Modified error handling in update() method - Detects lock errors and appends the helpful tip inline
3. Added test case - Verifies the complete error message including the helpful tip is displayed

User Experience:

When users hit the lock error, they now see:

Error: Another update is currently in progress. You may need to run `wp option delete core_updater.lock` after verifying another update isn't actually running.

This makes the error message actionable without requiring users to read the help text.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Proposal: clear core_updater.lock when update is forced?</issue_title>
<issue_description>I wanted to run this past the maintainers before preparing a pull request:

When running wp core update --force, the process will still abort if another update had been attempted but failed (for example, if the core_updater.lock option was left behind after a failed update). Would it make sense for --force to explicitly clear any locks that might exist, or might this be better served by a new option (e.g. --ignore-lock)?</issue_description>

<agent_instructions>Implement the suggestion to show the tip for using wp option delete core_updater.lock if that specific error happens.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@schlessera Right now, the help already provides a solution to this by explaining the problem and providing a separate command as a solution: ``` If you see "Error: Another update is currently in progress.", you may need to run `wp option delete core_updater.lock` after verifying another update isn't actually running. ```

I'm not sure having --force remove the lock automatically (and potentially corrupting the install because an update was indeed in progress) is an improvement...

Maybe we can make the above text appear when you actually hit the issue?</comment_new>

• Fixes Proposal: clear core_updater.lock when update is forced? #102

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[wojsmol]

@swissspidy This looks like testing of wp-cli/entity-command

[swissspidy]

You mean we should remove the assertion here?

[wojsmol]

IMHO yes, tests fot then wp-cli/entity-commad are in the command repo.

[codecov]

Codecov Report

❌ Patch coverage is 62.50000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Core_Command.php	62.50%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!