ARCHIVED TRAINING / hdmf-dev/hdmf
hdmf-dev__hdmf-1270
This is a preserved training example. Membership in the current training wave has not been verified.
Problem statement
[Bug]: get_data_shape on list of Data objects is incorrect
### What happened?
`get_data_shape` is used in many places, including shape validation and getting dimension labels. In NWB, an `Image` neurodata type is a descendent of `Data`, i.e., a dataset. `ImageReferences` has a field that stores a 1-D list/array of `Image` objects. However, when validating the shape of input to that field in `ImageReferences`, `get_data_shape` recurses into the `Image` data to get the shape of the images. As a result, a 1-D list of references to `Image` objects, which on disk has shape `(N, )`, will be reported by `get_data_shape` as having shape `(N, W, H)`. where (W, H) is the shape of the first image. The schema says the field should have shape `(N, )`.
Secondly, writing valid `ImageReferences` produces a warning on write:
/Users/rly/Documents/NWB/hdmf/src/hdmf/build/objectmapper.py:874: IncorrectDatasetShapeBuildWarning: Shape of data does not match shape in spec 'ImageReferences'
warnings.warn(msg, IncorrectDatasetShapeBuildWarning)
This occurs when getting dimension labels.
`get_data_shape` on a list/array of Data objects (a dataset of references) should return the shape of the list/array and not recurse deeper.
### Steps to Reproduce
```python
get_data_shape([Data(name="a", data=[1, 2]), Data(name="b", data=[3, 4])])
```
### Traceback
```pytb
```
### Operating System
macOS
### Python Version
3.13
### Package Versions
_No response_
Training membership
opd_e4b_cispo_v5 opd_e4b_pure_v6a opd_e4b_pure_v6b opd_e4b_pure_v7 opd_e4b_pure_v7b
Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.
Task and snapshot provenance
Snapshot captured 2026-11-12T17:06:59.476467+00:00 · Autoresearch-Arena/gemma-4-developer-agent
{
"datasets": [
"opd_e4b_cispo_v5",
"opd_e4b_pure_v6a",
"opd_e4b_pure_v6b",
"opd_e4b_pure_v7",
"opd_e4b_pure_v7b"
],
"examples": 29,
"instance_id": "hdmf-dev__hdmf-1270",
"problem_statement": "[Bug]: get_data_shape on list of Data objects is incorrect\n### What happened?\n\n`get_data_shape` is used in many places, including shape validation and getting dimension labels. In NWB, an `Image` neurodata type is a descendent of `Data`, i.e., a dataset. `ImageReferences` has a field that stores a 1-D list/array of `Image` objects. However, when validating the shape of input to that field in `ImageReferences`, `get_data_shape` recurses into the `Image` data to get the shape of the images. As a result, a 1-D list of references to `Image` objects, which on disk has shape `(N, )`, will be reported by `get_data_shape` as having shape `(N, W, H)`. where (W, H) is the shape of the first image. The schema says the field should have shape `(N, )`.\n\nSecondly, writing valid `ImageReferences` produces a warning on write:\n /Users/rly/Documents/NWB/hdmf/src/hdmf/build/objectmapper.py:874: IncorrectDatasetShapeBuildWarning: Shape of data does not match shape in spec 'ImageReferences'\n warnings.warn(msg, IncorrectDatasetShapeBuildWarning)\n\nThis occurs when getting dimension labels.\n\n`get_data_shape` on a list/array of Data objects (a dataset of references) should return the shape of the list/array and not recurse deeper.\n\n### Steps to Reproduce\n\n```python\nget_data_shape([Data(name=\"a\", data=[1, 2]), Data(name=\"b\", data=[3, 4])])\n```\n\n### Traceback\n\n```pytb\n\n```\n\n### Operating System\n\nmacOS\n\n### Python Version\n\n3.13\n\n### Package Versions\n\n_No response_",
"repo": "hdmf-dev/hdmf",
"source": "v2/experiments/train_data/opd_e4b_cispo_v5/verified_rft_messages.jsonl",
"source_sha256": "a43610ad0dfb6ace95375cfae09000f41afc0338cc925af870a4ade7a9b20c4c"
}{
"captured_at": "2026-11-12T17:06:59.476467+00:00",
"membership": "archived training",
"membership_evidence": "Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.",
"name": "Preserved post-training task archive",
"source": "Autoresearch-Arena/gemma-4-developer-agent",
"source_revision": "016496de222aaafca0d4ee4c18efc63ba616f76e",
"sources": [
{
"path": "v2/experiments/train_data/opd_e4b_cispo_v5/verified_rft_messages.jsonl",
"sha256": "a43610ad0dfb6ace95375cfae09000f41afc0338cc925af870a4ade7a9b20c4c"
},
{
"path": "v2/experiments/train_data/opd_e4b_hybrid_v3/verified_rft_messages.jsonl",
"sha256": "bd326303eb127e8e5e08f03daf97bb88d79d19709d59f3f93f348bc56686a8df"
},
{
"path": "v2/experiments/train_data/opd_e4b_onpolicy_v3/verified_rft_messages.jsonl",
"sha256": "960c680e797e823a0d3a22f4b1d5ef60a72971373d703b877340b0c9126aaf68"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v6a/verified_rft_messages.jsonl",
"sha256": "f045b7ca5b3883a1e2eaee81e1c02a4a1b53dd7b7b36e98bacb2ba5823a15148"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v6b/verified_rft_messages.jsonl",
"sha256": "0f62460a9706eea5e1605255896f191ab00cb5706c5f1f2e1c293e9a718218dc"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v7/verified_rft_messages.jsonl",
"sha256": "e37f7bd675322f3f81500b73559d60d5f602ca0537bf19f5cb06332c728c7b72"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v7b/verified_rft_messages.jsonl",
"sha256": "b864bdc8695183433eef6e31cb8d33fad44ba3aded2170c1ade4ad5b2944ce23"
},
{
"path": "v2/experiments/train_data/opd_e4b_self_audit_v4/verified_rft_messages.jsonl",
"sha256": "0026023745afb8f3dc1c176dc7f7171157b4ad5a66656b524af218e8e19ceee6"
},
{
"path": "v2/experiments/train_data/rft_e4b_aligned_v2/verified_rft_messages.jsonl",
"sha256": "92a4515fee9d152b0d4c510ee3ce4caaaffe2003ba7584469f8027f174aab18c"
},
{
"path": "v2/experiments/train_data/rft_v1/verified_rft_messages.jsonl",
"sha256": "a42453ccd7ac7680b0a03865e8e7080bc8bf74c8d9d193b440c441ed46f8512b"
},
{
"path": "v2/experiments/train_data/rft_v2/verified_rft_messages.jsonl",
"sha256": "18f4b3bd7e651f83c6acab479c9475e3fa50dc652a384f309e97146983ac85ba"
}
]
}