[BUG] Some device clusters not reporting attribute changes (by calling MatterReportingAttributeChangeCallback) when the invoked command is calling app::AttributeAccessInterface

[erwinpan1]

Reproduction steps

Currently there are many clusters using AccessInterface to delegate the attributes in the application layer. (e.g. MediaPlayback and MediaInput clusters . When the commands of these clusters are called, the attributes subscriber won't be able to receive the reportData.

Reproducing steps:

e.g.

1. running the a video player e.g. rootnode_basicvideoplayer_0ff86e943b

2. running 1st chip-tool to commission it and sharing it to the 2nd chip-tool

3. After the 2nd chip-tool successfully commissioned the device, subscribe the attribute change by interactive mode

$ ./out/chip-tool/chip-tool interactive start

>>> mediaplayback subscribe current-state 0 100 0x11 1

4. Then use 1st to invoke the Play or Pause

Expected results

The 2nd chip-tool as the attribute subscriber should get notified

Actual results

The 2nd chip-tool is not notified

Analysis

The current MediaPlayback simply calls the delegate to modify the attribute data but not calling MatterReportingAttributeChangeCallback media-playback-server.cpp

bool emberAfMediaPlaybackClusterPauseCallback(app::CommandHandler * command, const app::ConcreteCommandPath & commandPath,
                                              const Commands::Pause::DecodableType & commandData)
{
...
    Delegate * delegate = GetDelegate(endpoint);
    VerifyOrExit(isDelegateNull(delegate, endpoint) != true, err = CHIP_ERROR_INCORRECT_STATE);

    {
        delegate->HandlePause(responder);
    }
exit:
    if (err != CHIP_NO_ERROR)
    {
        ChipLogError(Zcl, "emberAfMediaPlaybackClusterPauseCallback error: %s", err.AsString());
        command->AddStatus(commandPath, Status::Failure);
    }

    return true;
}

When referring to correct implementation, it should be like the door-lock-server.cpp which calls MatterReportingAttributeChangeCallback after delegate successfully handles data changes.

void DoorLockServer::clearAliroReaderConfigCommandHandler(CommandHandler * commandObj, const ConcreteCommandPath & commandPath)
{
...

    uint8_t buffer[kAliroReaderVerificationKeySize];
    MutableByteSpan readerVerificationKey(buffer);
    CHIP_ERROR err = delegate->GetAliroReaderVerificationKey(readerVerificationKey);
...
    err = delegate->ClearAliroReaderConfig();
    if (err != CHIP_NO_ERROR)
    {
        ChipLogError(Zcl, "[SetAliroReaderConfig] Unable to set aliro reader config [endpointId=%d]", endpointID);
    }
    else
    {
        // Various attributes changed; mark them dirty.
        MatterReportingAttributeChangeCallback(endpointID, Clusters::DoorLock::Id, AliroReaderVerificationKey::Id);
        MatterReportingAttributeChangeCallback(endpointID, Clusters::DoorLock::Id, AliroReaderGroupIdentifier::Id);
        MatterReportingAttributeChangeCallback(endpointID, Clusters::DoorLock::Id, AliroGroupResolvingKey::Id);
    }
    sendClusterResponse(commandObj, commandPath, ClusterStatusCode(StatusIB(err).mStatus));
}

Bug prevalence

Everytime

GitHub hash of the SDK that was being used

2b5194b

Platform

core

Platform Version(s)

No response

Anything else?

No response