Skip to content

Conversation

@anlancs
Copy link
Contributor

@anlancs anlancs commented Oct 17, 2025

This reverts commit 243e27a.

It needs to be very strict, otherwise, all the commands that return CMD_WARNING_CONFIG_FAILED (and other errors) will be imperceptibly ommitted, seriously affecting the functionality.

This reverts commit 243e27a.

It needs to be very strict, otherwise, all the commands that return
`CMD_WARNING_CONFIG_FAILED` (and other errors) will be imperceptibly
ommitted, seriously affecting the functionality.

Signed-off-by: anlan_cs <[email protected]>
@ton31337
Copy link
Member

IMO, it's reverse. Restarting the service on a wrong command is not what I should expect as an operator, TBH.

@anlancs
Copy link
Contributor Author

anlancs commented Oct 21, 2025

IMO, it's reverse. Restarting the service on a wrong command is not what I should expect as an operator, TBH.

Without this revert, the caller need check all these errors (including failed, and others) themself, it is impossible.

@donaldsharp
Copy link
Member

We've gone back and forth multiple times on this. What is the correct behavior that we want here? I don't want to keep going back and forth over and over. Do we need a new/different approach to the whole problem?

@anlancs
Copy link
Contributor Author

anlancs commented Oct 22, 2025

The initial design is correct: @donaldsharp @ton31337

  1. The caller only ensure all are indeed known commands, must not unknown commands.
  2. Return failure to the caller ( better to give detail information to user with failed commands ), these commands have been known commands.

So, to fix PR 13888, the caller need add check to ensure all commands are known.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants