Skip to content

[Rust] Invalid codegen for composite type with multiple fields and different sinceVersion #1057

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

Closed
marciorasf opened this issue Mar 18, 2025 · 5 comments

Comments

@marciorasf
Copy link
Contributor

For the sample schema:

<sbe:messageSchema
	xmlns:ns2="http://www.fixprotocol.org/ns/simple/1.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:sbe="http://fixprotocol.io/2016/sbe"
	package="b3.entrypoint.fixp.sbe"
	id="1"
	version="4"
	semanticVersion="8.2.3"
	description="B3 Binary Entrypoint FIXP messages"
	byteOrder="littleEndian"
	xsi:schemaLocation="http://fixprotocol.io/2016/sbe sbe.xsd">
	<types>
		<set name="EventIndicator" encodingType="uint8" description="Set of indicators for a given event. First use case: indicates possible retransmission of message during recovery process." sinceVersion="4">
			<choice name="PossResend" description="1=Message is sent during recovery process, 0=Normal message.">0</choice>
		</set>
		<composite name="messageHeader" description="Message identifiers and length of message root.">
			<type name="blockLength" primitiveType="uint16" description="Length of the root of the FIX message contained before repeating groups or variable/conditions fields."/>
			<type name="templateId" primitiveType="uint16" description="Template ID used to encode the message."/>
			<type name="schemaId" primitiveType="uint16" description="ID of the system publishing the message."/>
			<type name="version" primitiveType="uint16" description="Schema version."/>
		</composite>
		<composite name="OutboundBusinessHeader" description="Header used for outbound business messages.">
			<ref name="sessionID" type="SessionID"/>
			<ref name="eventIndicator" type="EventIndicator" sinceVersion="4"/>
		</composite>
	</types>

	<sbe:message name="ExecutionReport_New" id="200" description="Execution Report - New message is sent in response to a NewOrderSingle or SimpleNewOrder messages, or also from a restated iceberg order.">
		<field name="businessHeader" type="OutboundBusinessHeader" id="35524" description="Common header to all outbound business messages."/>
	</sbe:message>
</sbe:messageSchema>

CLI tool 1.34.1 generates Rust code that doesn't compile due to:

error[E0599]: the method `acting_version` exists for reference `&OutboundBusinessHeaderDecoder<P>`, but its trait bounds were not satisfied
   --> crates/b3_entrypoint_fixp_sbe/src/outbound_business_header_codec.rs:122:21
    |
73  |     pub struct OutboundBusinessHeaderDecoder<P> {
    |     ------------------------------------------- doesn't satisfy `OutboundBusinessHeaderDecoder<P>: ActingVersion`
...
122 |             if self.acting_version() < 4 {
    |                     ^^^^^^^^^^^^^^ method cannot be called on `&OutboundBusinessHeaderDecoder<P>` due to unsatisfied trait bounds
    |
note: trait bound `P: ActingVersion` was not satisfied
   --> crates/b3_entrypoint_fixp_sbe/src/outbound_business_header_codec.rs:80:25
    |
78  |     impl<'a, P> ActingVersion for OutboundBusinessHeaderDecoder<P>
    |                 -------------     --------------------------------
79  |     where
80  |         P: Reader<'a> + ActingVersion + Default,
    |                         ^^^^^^^^^^^^^ unsatisfied trait bound introduced here
help: consider restricting the type parameter to satisfy the trait bound
    |
73  |     pub struct OutboundBusinessHeaderDecoder<P> where P: ActingVersion {
    |                                                 ++++++++++++++++++++++

OutboundBusinessHeaderDecoder does implement self.acting_version(), but just for a P: Reader<'a> + ActingVersion + Default:

impl<'a, P> ActingVersion for OutboundBusinessHeaderDecoder<P>
where
    P: Reader<'a> + ActingVersion + Default,
{
    #[inline]
    fn acting_version(&self) -> u16 {
        self.parent.as_ref().unwrap().acting_version()
    }
}

And error occurs because it's trying to use self.acting_version() for a P that does not implement ActingVersion:

impl<'a, P> OutboundBusinessHeaderDecoder<P>
where
    P: Reader<'a> + Default,
{
    /// BIT SET DECODER
    #[inline]
    pub fn event_indicator(&self) -> event_indicator::EventIndicator {
        if self.acting_version() < 4 {
            return event_indicator::EventIndicator::default();
        }

        event_indicator::EventIndicator::new(self.get_buf().get_u8_at(self.offset))
    }
}

It's the same error as the issue 1028, but for a slightly different schema.

On issue 1028, the type OutboundBusinessHeader had just one field: eventIndicator. In this new issue, OutboundBusinessHeader has two fields: sessionId and eventIndicator. It's the addition of sessionID that causes the error. More specifically, it's the addition of sessionID as the first field that breaks it, when I moved it to be the second field, the generated code compiled successfully.

Looking at the PR that solved the other issue, the solution was to get the version of the first field instead of the version of the type itself. I guess it always works when there's just one field, but for the scenario where we have multiple fields AND the one with version > 0 is not the first, that solution doesn't work.

It seems to me that the solution is to get the version from the field with the greatest version instead of the first one, but I'm not sure about how this could impact other parts of code generation. Is that indeed the actual solution? Is there a better alternative?

@marciorasf
Copy link
Contributor Author

I implemented the change to get the greatest version of inner fields instead of the first and it fixed the problem: PR #1058

@marciorasf marciorasf changed the title [Rust] Invalid Invalid codegen for composite type with multiple fields and different sinceVersion [Rust] Invalid codegen for composite type with multiple fields and different sinceVersion Mar 27, 2025
@vyazelenko
Copy link
Contributor

@mward Can you have a look at the proposed fix? Thanks.

@mward
Copy link
Contributor

mward commented Apr 8, 2025

I'll take a look, hopefully I'll have some time in the next day or two

@mward
Copy link
Contributor

mward commented Apr 25, 2025

Thanks @marciorasf, this looks great! Sorry it took me so long to look at.

@vyazelenko
Copy link
Contributor

PR #1058 was merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants