Where should properties like message_id, correlation_id, etc. be set in an amqp message?

[amarzavery]

3.2.4    Properties
Immutable properties of the message.
<type name="properties" class="composite" source="list" provides="section">
<descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/>
<field name="message-id" type="*" requires="message-id"/>
<field name="user-id" type="binary"/>
<field name="to" type="*" requires="address"/>
<field name="subject" type="string"/>
<field name="reply-to" type="*" requires="address"/>
<field name="correlation-id" type="*" requires="message-id"/>
<field name="content-type" type="symbol"/>
<field name="content-encoding" type="symbol"/>
<field name="absolute-expiry-time" type="timestamp"/>
<field name="creation-time" type="timestamp"/>
<field name="group-id" type="string"/>
<field name="group-sequence" type="sequence-no"/>
<field name="reply-to-group-id" type="string"/>
</type>
The properties section is used for a defined set of standard properties of the message. The properties section is
part of the bare message; therefore, if retransmitted by an intermediary, it MUST remain unaltered.

As per the AMQP 1.0 specification, I thought that the predefined message properties should be sent inside a property named properties as follows in an amqp message object:

const request: any = {
         body: tokenObject.token,
        properties: { //properties object..
           message_id: uuid(),
           reply_to: this.replyTo,
           to: this.endpoint,
        },
        application_properties: {
          operation: Constants.operationPutToken,
          name: audience,
          type: tokenObject.tokenType
        }

Usually the service would send back a message which has correlation_id in it. However that did not happen.
Instead when I sent those predefined properties as top level properties as described below then the service did send me a message with correlation_id in it.

const request: any = {
        body: tokenObject.token,
        message_id: uuid(), // Top level property
        reply_to: this.replyTo, // Top level property
        to: this.endpoint, // Top level property
        application_properties: {
          operation: Constants.operationPutToken,
          name: audience,
          type: tokenObject.tokenType
        }
      };

Thus it seems to me like all the predefined properties need to be sent as top level properties.

I am not sure if the service is doing something wrong over here. However, wanted to know if rhea was expecting all the predefined properties as top level properties inside the AMQP message.

[grs]

Yes that is correct, the properties are all top level objects. There is some tension between closely following the spec and making the library intuitive for users who don't know the spec. The properties were one such trade-off. (At one point rhea supported both, but that ended up being more confusing)

[amarzavery]

Oops. Can this be documented in the README.md? This would help other people. Typescript type definitions would have been so useful in this case.
Thank you so much for all the prompt responses.

[amarzavery]

/cc @anthonyvercolano - message_id will be a top level property.

[grs]

The README.md does briefly describe the message fields in text for Sender.send(). Would probably be clearer to have a distinct section on message format and refer to that from relevant places.

[amarzavery]

@grs - Some follow up questions:

• How should predefined properties actually be serialized on the wire? Does message_id go under properties (rhea does it for us)? or it actually remains as a top level property on the wire as well?
• What about application_properties and message_annotations? Should they be flattened as well or should remain inside their property names?

I am still a newbie with AMQP hence some of those questions may seem silly..

[grs]

rhea will encode everything correctly on the wire i.e. properties will be in a proper properties section.

application-properties and message-annotations are in nested maps as the names of those are not known in advance

[amarzavery]

cool that makes sense. Thank you :).