Python ecCodes: inputExtendedDelayedDescriptorReplicationFactor ignored when creating BUFR from sample with delayed replication sequence 315012

[twsearle]

What happened?

Summary

I am seeing what looks like a write/encode issue in Python ecCodes when creating a BUFR message from BUFR4 sample and using delayed replication sequence 315012.

repro_eccodes_315012_delayed.py

Description

Python ecCodes appears to ignore delayed replication input factors when encoding BUFR from a BUFR4 sample using sequence 315012. In my repro (ecCodes Python 2.41.0), setting inputDelayedDescriptorReplicationFactor=[1] and inputExtendedDelayedDescriptorReplicationFactor=[50] still unpacks/encodes as replication factor 1 (len(depthBelowWaterSurface)=1, len(year)=3) instead of 50 levels. Reading existing delayed-replication files works correctly in the same environment (e.g. extendedDelayedDescriptorReplicationFactor=[933] decodes to len(depthBelowWaterSurface)=933), so this seems specific to the Python write/encode path from sample.

Environment

OS: Linux
Python: 3.12.12
ecCodes Python module: 2.41.0
Minimal repro script:
See repro_eccodes_315012_delayed.py attached

Repro summary

1. Create handle from codes_bufr_new_from_samples("BUFR4")
2. Set keys:

masterTableNumber=0
masterTablesVersionNumber=40
localTablesVersionNumber=0
dataCategory=31
dataSubCategory=110
numberOfSubsets=1
observedData=1
compressedData=0

3. Set:

unexpandedDescriptors=[315012]
inputDelayedDescriptorReplicationFactor=[1]
inputExtendedDelayedDescriptorReplicationFactor=[50]

4. Call unpack

Observed:

• extendedDelayedDescriptorReplicationFactor is [1] (not [50])
• len(depthBelowWaterSurface) is 1 (not 50)
• len(year) is 3 (not 52)
• After pack + reopen + unpack, values remain the same ([1], lengths for 1 level).

Expected:

Delayed replication input factors should be honored, giving a 50-level profile block:

• extendedDelayedDescriptorReplicationFactor=[50]
• len(depthBelowWaterSurface)=50
• len(year)=52

Additional control:

Reading existing BUFR files that already contain delayed replication works correctly in the same environment.
For example a file with:

unexpandedDescriptors=[315012]
extendedDelayedDescriptorReplicationFactor=[933]
decodes with len(depthBelowWaterSurface)=933.

So decode appears OK; the issue seems specific to creating/encoding from sample in Python API.

What are the steps to reproduce the bug?

Run the attached repro script.

Version

2.41.0

Platform (OS and architecture)

Linux 5.14.0-611.41.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Mar 7 05:13:00 EST 2026 x86_64 x86_64 x86_64 GNU/Linux

Relevant log output

Accompanying data

No response

Organisation

Met Office

[shahramn]

Please see https://confluence.ecmwf.int/display/UDOC/Encoding+of+Delayed+Replications-+ecCodes+BUFR+FAQ

[joobog]

The order of keys is important in BUFR. Please set the delayed replication keys first, then set the descriptors.

inputDelayedDescriptorReplicationFactor=[1]
inputExtendedDelayedDescriptorReplicationFactor=[50]
unexpandedDescriptors=[315012]

We'll improve the error message to prevent this this from being overlooked.

[twsearle]

The order of keys is important in BUFR. Please set the delayed replication keys first, then set the descriptors.

inputDelayedDescriptorReplicationFactor=[1]
inputExtendedDelayedDescriptorReplicationFactor=[50]
unexpandedDescriptors=[315012]

We'll improve the error message to prevent this this from being overlooked.

I think I am just generally experiencing a lot of confusion about the workings of sequence-style delayed replication. I have a file that uses delayed replication factor keys: a delayedDescriptorReplicationFactor key and an extendedDelayedDescriptorReplicationFactor key. I was struggling to replicate the file using the 0315012 as a template. I managed to do it by explicitly listing all the different element descriptors though. I think I am there on this after revisiting the course and trying again fixing the order of things. It is a bit tricky because I am struggling with different centres representing the same glider data in different ways (you would hope we could all agree to use the 0315012 sequence in the same way but such is life!). Thanks very much for your help!