-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Return InvalidCommand instead of UnsupportedCluster if the command is not handled in CHI #37166
base: master
Are you sure you want to change the base?
Conversation
5701090
to
990f32f
Compare
c7022c9
to
5c36f8c
Compare
ec0298a
to
289c07d
Compare
PR #37166: Size comparison from 435583e to 289c07d Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
src/app/zap-templates/templates/app/im-cluster-command-handler.zapt
Outdated
Show resolved
Hide resolved
….zapt Co-authored-by: Boris Zbarsky <[email protected]>
PR #37166: Size comparison from 435583e to 25cb68d Full report (3 builds for cc32xx, stm32)
|
PR #37166: Size comparison from c56eb2b to 7ed7fff Full report (72 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
@@ -75,7 +75,7 @@ Protocols::InteractionModel::Status DispatchServerCommand(CommandHandler * apCom | |||
|
|||
} // namespace Clusters | |||
|
|||
void DispatchSingleClusterCommand(const ConcreteCommandPath & aCommandPath, TLV::TLVReader & aReader, CommandHandler * apCommandObj) | |||
void DispatchSingleClusterCommand(const ConcreteCommandPath & aCommandPath, TLV::TLVReader & aReader, CommandHandler * apCommandObj, bool aClusterIsValid) |
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.
void DispatchSingleClusterCommand(const ConcreteCommandPath & aCommandPath, TLV::TLVReader & aReader, CommandHandler * apCommandObj, bool aClusterIsValid) | |
void DispatchSingleClusterCommand(const ConcreteCommandPath & aCommandPath, TLV::TLVReader & aReader, CommandHandler * apCommandObj, bool aClusterExists) |
and similar throughout.
else | ||
{ | ||
ChipLogError(Zcl, "Unknown cluster " ChipLogFormatMEI, ChipLogValueMEI(aCommandPath.mClusterId)); | ||
errorStatus = Protocols::InteractionModel::Status::UnsupportedCluster; |
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.
How do you know it's not UnsupportedEndpoint?
Again, test coverage would flush out these edge cases...
But I have to admit, now that I think this through more, that none of this is making sense to me. I would have assumed that in general we only reach this point after we have already validated that the cluster and whatnot exist (since we have to do ACL checks before we get here), no? So shouldn't the return status here just always be UnsupportedCommand, period?
Currently, after switching to CHI, any unhandled command is returning Protocols::InteractionModel::Status::UnsupportedCluster. Previously, when Ember handled these commands, we would return Protocols::InteractionModel::Status::InvalidCommand. We should preserve that behavior and continue returning InvalidCommand for runhandled commands in CHI.
Testing
Verified by manually disable command Commands::ResetCounts in WiFiDiagnosticsServer