Fix GetPropertyDataReply to send proper JSON header instead of empty content #62
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…content - PropertyHostFacade::process_get_property_data now returns proper JSON header with error status when no property rules are set - Matches Kotlin implementation behavior of returning structured responses - Fixes issue where both header and body were sent as empty, which is invalid - Uses PropertyExchangeStatus::RESOURCE_UNAVAILABLE_OR_ERROR for consistent error reporting Co-Authored-By: Atsushi Eno <atsushieno@gmail.com>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
- Add CommonRulesPropertyService class implementing MidiCIServicePropertyRules interface - Initialize property_rules_ in PropertyHostFacade constructor with CommonRulesPropertyService - Implement getPropertyData with proper device info, channel list, and resource list JSON responses - Add all required interface methods: get_property_id_for_header, create_update_notification_header, etc. - Use CommonRulesKnownMimeTypes::APPLICATION_JSON for proper MIME type constants - Remove temporary fix since service now handles all property requests with structured responses - Follows Kotlin implementation pattern for property data exchanges with proper status codes Co-Authored-By: Atsushi Eno <atsushieno@gmail.com>
- Change get_property_ids() to return JSON_SCHEMA in default property list - Add create_json_schema_json() method to handle JSON schema property - Handle RESOURCE_LIST as special case that returns complete metadata list - Update get_metadata_list() to work with abstract PropertyMetadata class - Matches Kotlin implementation behavior exactly Co-Authored-By: Atsushi Eno <atsushieno@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix GetPropertyDataReply to send proper JSON header instead of empty content
Problem
The C++
Messengerclass was sending invalidGetPropertyDataReplymessages with both header and body as empty, which violates the MIDI-CI Property Exchange specification.Solution
Modified
PropertyHostFacade::process_get_property_data()to return a proper JSON header with error status when no property rules are configured, matching the Kotlin implementation behavior.Changes
process_get_property_data()method to create proper JSON header withPropertyExchangeStatus::RESOURCE_UNAVAILABLE_OR_ERRORstatusTestPropertyRules::get_property_data()for consistent JSON header creationTesting
Technical Details
The fix ensures that when no property rules are set, instead of returning empty header/body (which is invalid), the C++ implementation now returns:
This matches the Kotlin implementation's approach of always providing structured responses rather than empty content.
Link to Devin run: https://app.devin.ai/sessions/e13a8a5bc47d4ebf8f8c0b2cbd93d6a2
Requested by: Atsushi Eno (atsushieno@gmail.com)