[Bug]: juce_midi_ci property host does not expect Reply To Subscription in reply to Subscription messages

[atsushieno]

Detailed steps on how to reproduce the bug

Common Rules for Property Exchange v1.1 specification (along with MIDI-CI v1.2 Property Exchange specification), section 9.2 in particular, expects that the subscribers "shall" send the Reply to Subscription to the property host about its processing result:

A device that receives a Subscription message for any subscribed Resource Data shall reply with a Reply to Subscription message, so the original sender is aware of the success or failure of a command.

There is no conditional term whether the actual command is "full", "partial", or "notify".

Current JUCE property host implementation does not seem to expect this (it does not seem to have any input message handler for PropertySubscribeResponse), resulting in InvalidateMUID. Then our further Get Property Data requests are disregarded as our MUID is invalidated.

I noticed this while implementing my own MIDI-CI client (in Kotlin), same as issue #1323.

Repro steps (I name "CapabilityInquiryDemo" here, but the actual cause is somewhere in juce_midi_ci module):

• Launch CapabilityInquiryDemo
• Launch another MIDI-CI client that can connect to CapbilityInquiryDemo through a pair of MIDI ports
• On CapabilityInquiryDemo,
  • connect the MIDI ports
  • switch to "Local Configuration" tab, enable "Properties", create a property ("+") and that "Can Subscribe"
• On the client, send Discovery to find the CapabilityInquiryDemo app, and retrieve ResourceList to find the property that was defined by the steps above.
• On the client, (select the property, depending on its UI, and) send Property Subscription message.
• Confirm the Reply to Subscription message that was sent back from CapabilityInquiryDemo (should be also logged at CapabilityInquiryDemo).
• On CapabilityInquiryDemo,
  • select "Subscribers" tab and confirm that the client MUID is shown there
  • select "Value" tag on the property configuration on the "Local Configuration" tab, click "Set Full..." button and choose some JSON file to update the property value.
• On the client,
  • confirm that it received "Subscription" message with "notify" command (which can be "full" or "partial", depending on how JUCE evolves the implementation, but as of reporting this "notify" seems the only command it can send).
  • Send "Reply to Subscription" message with {"status": 200} header.

CapabilityInquiryDemo returns InvalidateMUID after the steps above.

What is the expected behaviour?

It should expect Reply to Subscription in response to property updates via Subscription.

They can just be discarded, but should not result in "Invalidate MUID".

Operating systems

macOS

What versions of the operating systems?

13.5.2 (22G91)

Architectures

ARM

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct

[atsushieno]

I forgot to mention: Common Rules for PE specification, section 9.4 (Example Set of Transactions with Initiator Subscribing to Responder Resources) contains an exact case that Subscription message for "notify" ({"command":"notify","subscribeId":"sub138047"}) that results in Reply to Subscription ({"status":200}), at Page 42.

[reuk]

Thanks for the detailed report.

Unfortunately, I haven't been able to reproduce the issue exactly as you describe so far. Currently, I'm testing with two copies of the CapabilityInquiryDemo talking to each other.

I do see some potentially-related bugs in the area of property exchange.

• At the moment, there's an issue with how we handle cancelled notifications. When a JUCE ci::Device requests to begin or end a subscription, it immediately sends a PropertyNotify message after that request, which terminates the subscription again. It looks like this bug affects JUCE initiators beginning/ending a subscription, so I think this is separate to the issue you're seeing, given that you're initiating the subscription from a non-JUCE app.

  • Looking back over the code, I think I know how to fix this, but it's also uncovered some other places where things aren't as robust as they could be. Hopefully I can have a fix up in the next few days, depending on how big a change this ends up being!

• If I hack in a quick workaround for the above issue, then things seem to work as expected:

  • The broadcaster sends a Property Subscribe message with the header {"command":"notify","resource":"X-CustomProp","subscribeId":"0"}
  • The subscriber sends a Property Get Data message with the header {"resource":"X-CustomProp"}
  • The subscriber sends a Property Subscribe Response with the header {"status":200,"subscribeId":"0"}
  • The broadcaster sends a Property Get Data Response with {"status":200}

I think that the subscribeId in the Property Subscribe Response above is unnecessary, but I don't see any InvalidateMUID messages being sent even if I remove this field from the Reply to Subscription header.

Are you able to provide the exact bytes of the sysex messages that you're sending to the Demo? That seems like the simplest way of repro-ing the bug. Otherwise, maybe you could stick a breakpoint in OutputHandler::processMessage in the Demo and see how the callstack looks at the point where InvalidateMUID is sent. I'd expect the callstack to provide some hints as to which message caused the InvalidateMUID reply.

[atsushieno]

Thanks for the details. Upon further investigation I figured that it was MY bug - my Reply to Subscription had indeed wrong MUID. After fixing the issue the property Subscription updates worked well. Sorry for the noise!

I'm closing the issue as the issue itself is invalid but if you prefer keeping it open (for the issues you discovered as above) please do so.

[reuk]

Thanks for reporting. We've pushed some fixes for the issues I discovered while debugging:

• The correct status code is now sent when terminating a request via notify
• The subscribeId is no longer included in replies to property subscription updates
• The property request and subscription APIs have been updated to make it easier to manage ongoing requests, and to automatically retry subscription-start requests: https://github.com/juce-framework/JUCE/commit/60757de2f205096287eff625a9594cc7bfbfb4df