[BUG]: Adding error section to existing method inserts error byte into first byte of reply body rather than last byte of SOME/IP header

[srl100]

vSomeip Version

v3.4.10

Boost Version

1.81

Environment

Embedded Linux

Describe the bug

[Issue copied from capicxx-someip-tools#49 - I will close it there if this is a better place for it]

I have a method defined in .fidl that works OK, taking a UInt32 input parameter and returning a 4 byte data structure. When I add an error clause to the method in the .fidl file and add the error behaviour in the stub implementation the error code gets inserted into the first byte of the SOME/IP data field rather than the last byte of the SOME/IP header.

Reproduction Steps

I have a method defined in .fidl that works OK, taking a UInt32 input parameter and returning a 4 byte data structure, e.g.

SOME/IP Protocol (Service ID: 0x433f, Method ID: 0x0103, Length: 12)
    Service ID: 0x433f
    Method ID: 0x0103
    Length: 12
    Client ID: 0x0000
    Session ID: 0x0001
    SOME/IP Version: 0x01
    Interface Version: 0x01
    Message Type: 0x80 (Response)
    Return Code: 0x00 (Ok)
    Payload: 00000000

I now want to do extend my code to do some validity checking on the input parameter and insert a non-zero return code into the SOME/IP reply header if the checking fails.

I have naiively added an error clause to my .fidl and updated my implementation to fill in the error code, but all that seems to do is to insert my error code byte into the start of the data, i.e. returning 5 bytes of user data instead of 4 bytes.

SOME/IP Protocol (Service ID: 0x433f, Method ID: 0x0103, Length: 13)
    Service ID: 0x433f
    Method ID: 0x0103
    Length: 13        <--- Was 12
    Client ID: 0x0000
    Session ID: 0x0001
    SOME/IP Version: 0x01
    Interface Version: 0x01
    Message Type: 0x80 (Response)
    Return Code: 0x00 (Ok)   <--- Not what I want
    Payload: 3000000000

Note the change to the Length field and the extra "30" byte at the start of the data.

Here is my method specification with the new error section:

package commonapi.examples

interface Test {

  version {major 1 minor 0}

  enumeration eErrorCode {
    E_NO_ERROR=0x00                     /* No error */
    E_INVALID_INDEX=0x30                /* The requested index is out of range. */
  }

  struct sData {
    UInt32          Data1
  }

  method getData {
    in {
        UInt32 dataIndex
    }
    out {
        sData data
    }
    error eErrorCode
  }
}

My stub implementation is as follows:

#include "TestStubImpl.hpp"
#include <v1/commonapi/examples/Test.hpp>

using namespace v1::commonapi::examples;

TestStubImpl::TestStubImpl()
{
}

TestStubImpl::~TestStubImpl()
{
}

void TestStubImpl::getData(const std::shared_ptr<CommonAPI::ClientId> _client,
                                                uint32_t _dataIndex,
                                                getDataReply_t _reply)
{
    (void)_client;
    Test::eErrorCode error = Test::eErrorCode::E_INVALID_INDEX;
    Test::sData data = {};

    if (_dataIndex == 0UL)
    {
        error = Test::eErrorCode::E_NO_ERROR;
    }
    _reply(error, data);
}

In CommonAPI-SOMEIP_deployment_spec.fdepl I can see that SomeIpErrorCoding defaults to 'Header', but there does not appear to be another option - I don't know if that is relevant to this issue.

It looks to me like either I am missing a call into the SOME/IP stack to tell it that there has been an error, or alternatively that I am missing some configuration that tells the SOME/IP stack that the stub implementation of this method is providing the return code.

Any ideas?

Expected behaviour

The response I am expecting is:

SOME/IP Protocol (Service ID: 0x433f, Method ID: 0x0103, Length: 12)
    Service ID: 0x433f
    Method ID: 0x0103
    Length: 12
    Client ID: 0x0000
    Session ID: 0x0001
    SOME/IP Version: 0x01
    Interface Version: 0x01
    Message Type: 0x80 (Response)
    Return Code: 0x30 (<some sort of error code interpretation>)
    Payload: 00000000

Logs and Screenshots

No response

[srl100]

Added source files showing issue:

Test.zip

[srl100]

Anyone?