[XTypes] DataReader cannot handle extended/evolved (appendable) type

[lexamor]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

According to the XTypes spec:

Types with extensibility kind APPENDABLE are delimited if serialized with encoding version 2
(DELIMITED_CDR).
...
T1 is assignable-from T2 and T2 is a delimited type, then T1 is said to be
“strongly” assignable from T2

So, from my understanding of it the appendable (encoded) serialized type (using DELIMITED_CDR / XCDRv2 encoding) which contains more members than decoder knows, should be assignable.

Current behavior

The reader failed to handle extended/evolved (appendable) type and an appropriate error log message appeared:

Steps to reproduce

Define type on both the reader & writer sides in the IDL:

// DataWriter

  @appendable
  struct appendable
  {
      octet the_octet;
      short the_short;
      long the_long;
  };

// DataReader
  @appendable
  struct appendable
  {
      octet the_octet;
      short the_short;
  };

I.e. type is evolved and DataReader is not aware about the_long member.

Try to launch both publisher and subscriber apps, as a result, discovery is successful but communication does not happen.

Fast DDS version/commit

v2.13.1

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

UDPv4

Additional context

Seems, it happened because the chosen PREALLOCATED_WITH_REALLOC_MEMORY_MODE policy is switched to PREALLOCATED_MEMORY_MODE for some optimization purposes, but maybe it is not the case for extensible types.

A possible fix/workaround works/fixes issue for me, but not completely sure about its possible drawbacks.

diff --git a/src/cpp/fastdds/subscriber/DataReaderImpl.cpp b/src/cpp/fastdds/subscriber/DataReaderImpl.cpp
index 29e41e993..1e2ee5015 100644
--- a/src/cpp/fastdds/subscriber/DataReaderImpl.cpp
+++ b/src/cpp/fastdds/subscriber/DataReaderImpl.cpp
@@ -1776,7 +1776,8 @@ std::shared_ptr<IPayloadPool> DataReaderImpl::get_payload_pool()
     if (PREALLOCATED_WITH_REALLOC_MEMORY_MODE == history_.m_att.memoryPolicy &&
             (type_->is_bounded() || type_->is_plain()))
     {
-        history_.m_att.memoryPolicy = PREALLOCATED_MEMORY_MODE;
+        // history_.m_att.memoryPolicy = PREALLOCATED_MEMORY_MODE;
     }
 
     PoolConfig config = PoolConfig::from_history_attributes(history_.m_att);

XML configuration file

No response

Relevant log output

[RTPS_READER_HISTORY Error] Change payload size of '16' bytes is larger than the history payload size of '15' bytes and cannot be resized. -> Function can_change_be_added_nts

Network traffic capture

No response

[JLBuenoLopez]

@lexamor

Thanks for the report. I am afraid that, even though the XTypes specification is currently being refactored, the type evolution is not in the current roadmap. If you are interested on this XTypes feature, you might consider contacting with eProsima commercial support team for options to accelerate this development.

I am moving this ticket to the Ideas disccusion forum where feature requests are discussed.

[lexamor]

Thank you for your quick response.

As I see this use case is supported by the FastCDR (and covered by test)

So, looks like, only adjustments on the FastDDS are needed.

In general, I think it is quite an important thing because type evolution (backward compatibility) support is one of the major Extensible types features.