* Add Fortran ABI compatibility check to abi-report workflow
Mirrors the existing C/HL/C++ abi-dumper + abi-compliance-checker
steps for libhdf5_fortran.so, plus a supplementary nm-based exported
symbol diff since gfortran's mangled names don't encode argument
lists and DWARF-based diffing has not been validated against
Fortran-specific constructs (array descriptors, derived types).
* Auto-detect ABI reference release instead of hardcoding it
file_ref was pinned to '2.0.0' in both daily-build.yml and release.yml
and had gone stale across two releases (2.1.0, 2.1.1) without being
bumped, silently comparing against a two-versions-old baseline. Have
abi-report.yml query the GitHub API for the latest published
HDFGroup/hdf5 release when file_ref isn't explicitly given, so callers
no longer need to remember to update a pinned tag after every release.
Verified the resolution command returns 2.1.1 against the live API.
Also documents the expected false-positive pattern in the new Fortran
ABI check: abi-dumper misreads gfortran's DWARF encoding of
assumed-shape array descriptors as fixed array bounds, producing bulk
Low-severity noise on the KIND/RANK-generated H5_gen.F90 procedures
that isn't a real interface change.
* Various improvement in documentation and a decoding function
- Improves documentation on the type size when creating/accessing a compound datatype with no predefined struct (GH issue #5371)
- Provides better description of the min_meta_perc and min_raw_perc arguments in the H5Pset_page_buffer_size() (GH issue #5711)
- Adds error checkings to an internal decoding function
* Corrected the checks, the base address equals the end-of-file is valid.
* Skip for multi-file and split drivers when validating addresses against stored_eof
* Committing clang-format changes
* Remove incorrect name
* Fix typos
* Modified description of type_size arguments
* Used a more robust condition when checking EOF
* Corrected incorrect conflict resolving
* Update src/H5Fsuper_cache.c
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* Update src/H5Fsuper_cache.c
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* Committing clang-format changes
* Modified per feedbacks.
* Fix comparison per feedbacks
* Omit unused parameter name in a catch block
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Neil Fortner <fortnern@gmail.com>
* fix: pre-size filter output buffer to avoid realloc fragmentation on Windows
When reading a filtered (compressed) chunk, filters like deflate initialize
their output buffer using *buf_size (the pipeline's buffer capacity hint).
With *buf_size set to chunk_disk_size (the compressed size), deflate grows
its output buffer via repeated realloc() doubling. On Windows this fragments
the heap and causes read times to increase steadily across iterations.
Set buf_alloc to MAX(chunk_disk_size, chunk_size) immediately before calling
H5Z_pipeline so filters pre-allocate their output at the full uncompressed
size and avoid realloc. The inbuf is still allocated at chunk_disk_size —
only the hint passed to the pipeline is enlarged — so there is no
double-large-allocation overhead and peak memory stays at
chunk_disk_size + chunk_size rather than 2 * chunk_size.
For incompressible chunks where chunk_disk_size > chunk_size the hint
remains at chunk_disk_size, satisfying H5Z_pipeline's post-filter size
validation.
Fixes#4481 and #4513.
* fix: return nbytes instead of *buf_size in nbit and scaleoffset no-op paths
Per the HDF5 filter API, nbytes is the count of valid data bytes in the
buffer, while *buf_size is the allocated buffer capacity. These two values
were historically always equal on the read path, so either worked in
practice. The pre-sizing change (which sets buf_alloc = chunk_size before
the filter pipeline) makes *buf_size > nbytes for compressed reads,
exposing the latent bug.
In H5Znbit.c: the no-compress pass-through (cd_values[1] == 1) was
returning *buf_size, causing the next filter (e.g. fletcher32) to treat
the full pre-sized buffer as valid data and compute a checksum over
uninitialised bytes.
In H5Zscaleoffset.c: the no-process path had the same pattern. No current
test exercises this path through a multi-filter pipeline where the size
mismatch would be observable, but the fix is correct by the same API
reasoning.
* experiment: deflate decompress reuses inbuf via H5resize_memory
Instead of allocating a fresh output buffer (H5MM_malloc), copy the
compressed input to a small temp buffer and resize *buf in-place via
H5resize_memory. On Windows, HeapReAlloc can often extend an existing
heap block without moving it, avoiding the cost of finding and committing
a fresh large allocation for every chunk read.
This is combined with the pre-sizing hint in H5Dchunk.c that sets
buf_alloc = chunk_size before the pipeline call, so the resize goes
directly to chunk_size in one step with no realloc loop.
* fix: pre-resize chunk buf in H5Dchunk.c so all filters see correct capacity
Replace the hint-only buf_alloc enlargement with an actual
H5D__chunk_mem_realloc() before calling H5Z_pipeline. Every filter now
sees *buf_size equal to the real buffer capacity, not just an advisory
hint. This fixes a bounds-check regression in H5Zscaleoffset where the
read path uses *buf_size as the end-of-buffer sentinel in
H5_IS_BUFFER_OVERFLOW and as the input-size argument to
H5Z__scaleoffset_decompress; an inflated hint caused false-negative
overflow checks and potential over-reads when scaleoffset is the on-disk
filter.
H5Zdeflate is simplified accordingly: the up-front H5resize_memory(*buf,
nalloc) is removed since the buffer is already at nalloc on entry. The
inbuf copy is retained (still needed to read compressed input while
writing uncompressed output into the same buffer), as is the
realloc-doubling loop for the uncommon case where output exceeds
chunk_size.
Also add test/chunk_deflate_perf.c, a standalone benchmark that times
per-chunk deflate reads over multiple passes to detect the steady read-time
increase caused by heap fragmentation on Windows (issues #4481 / #4513).
* Committing clang-format changes
* test: add file path argument to chunk_deflate_perf benchmark
Add optional 4th argument to specify the output HDF5 file path
(default: chunk_deflate_perf.h5 in CWD). Allows running develop
and fix builds against separate files so pass 1 is cold-cache for
both and the two runs don't share page-cache state.
* test: remove chunk_deflate_perf benchmark
Not suitable for the test suite; intended for manual Windows validation
only. Keep locally if needed.
* fix: pre-resize chunk buf in H5Dchunk.c so all filters see correct capacity
Allocate the chunk read buffer at MAX(chunk_disk_size, chunk_size) from
the start rather than allocating at chunk_disk_size and immediately
reallocating. The read only fills chunk_disk_size bytes regardless of
buffer size, so there is no cost to the larger initial allocation and the
separate realloc step is eliminated.
Every filter now receives *buf_size equal to the actual buffer capacity
with no additional allocation needed. On Windows a single HeapAlloc at
the correct size avoids the repeated realloc-doubling in the deflate
filter that fragments the heap and causes read times to increase over
successive iterations (issues #4481 / #4513). Also fixes the
scaleoffset bounds-check regression where *buf_size was used as an
end-of-buffer sentinel.
* revert: restore H5Dchunk.c and H5Zdeflate.c to pre-experiment state
Reverts the deflate in-place decompression experiment and the H5Dchunk.c
pre-sizing changes back to the state at 9ab5e191d7, keeping the nbit
and scaleoffset no-op path fixes.
* fix: allocate chunk buf at MAX(disk_size, chunk_size) before filter pipeline
The previous approach allocated the buffer at chunk_disk_size and then
bumped buf_alloc to chunk_size as a hint to the pipeline, causing *buf_size
to misrepresent the actual allocation. Any filter that writes up to
*buf_size bytes into *buf would overflow.
Allocate at MAX(chunk_disk_size, chunk_size) upfront so the buffer and
the hint given to filters are always consistent. For incompressible chunks
where chunk_disk_size >= chunk_size the allocation is unchanged.
* Use HGOTO_DONE(nbytes) for the scaleoffset no-op passthrough
Matches the macro convention used for the other early-return in this
function per bmribler's review comment on PR #6389.
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Fix NULL pointer access when H5A_operator2_t is NULL
Passing NULL for the callback function pointer to H5Aiterate2 and
H5Aiterate_by_name was not detected, leading to a subsequent access
of an uninitialized pointer. Add a check for this "no operator
specified" case in both functions so they fail gracefully instead.
Fixes GHSA-r7g4-hv2f-5c66 - CVE-2025-9274
* Fix format
* Fix Java test to handle NULL callback to H5Aiterate2
* Fix JNI datatype ID leak in h5str_detect_vlen_str()
The JNI H5Dread/H5Dwrite/H5Aread/H5Awrite wrappers call h5str_detect_vlen()
on the memory type. For an H5T_ARRAY/H5T_VLEN of a fixed (non-vlen-string)
base type, h5str_detect_vlen_str() acquired the base type via H5Tget_super()
but only closed it when the recursive check returned 1 or a negative error.
When the recursive call returned 0 because no vlen string was found, the base type ID
was leaked.
This PR changes h5str_detect_vlen_str() to close the id unconditionally after the recursive check,
in the same style as the compound-member case in the same function.
A JNI regression test exists at TestH5D.testH5DArray_super_no_id_leak, which reads
an H5T_ARRAY-of-int dataset in a loop and asserts via H5Fget_obj_count() that
no datatype IDs leak.
* Assert non-negative H5Fget_obj_count in array datatype ID leak test
Guard the before/after open-datatype counts against a negative
(failed) H5Fget_obj_count return, which would otherwise let the
equality check pass spuriously. Keep the count scoped to
H5F_OBJ_ALL: the leaked IDs are transient datatypes not attached to
any file, so a per-file count would not see them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Modify CHANGELOG entry
* Modify CHANGELOG again
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
Generate the Doxygen tag file inside the html output directory
(hdf5lib_docs/html/hdf5.tag) instead of at the build root. The S3
documentation publishing (daily "latest", release zip, and
publish-release) all derive from the docs-doxygen artifact, which is
uploaded from the build-tree html directory. Placing the tag file there
makes it flow to every destination, e.g.
https://support.hdfgroup.org/documentation/hdf5/latest/hdf5.tag
Since the tag file now lives inside html/, the existing DIRECTORY install
already installs it to ${HDF5_INSTALL_DOC_DIR}/html/hdf5.tag, so the
redundant standalone install(FILES ...) is removed (it would otherwise
reference a file that no longer exists at the build root).
* Add Next Release badge and Medium/Low priority progress badges
Adds a "Next Release" badge (in-development version from H5public.h)
and extends the existing Critical/High priority progress badges with
Medium (P2) and Low (P3) priority tracking, all fed from the same
GitHub Project #39 gist-based badge pipeline.
* Remove in-progress 2.0 entry from release schedule diagram
The Release Schedule chart is meant to show only past releases that
have reached end of life; the in-development series is now tracked
separately by the Release Progress badges. Regenerate the PNG from
the updated PlantUML source and clarify the README wording.
* Add Latest Release badge and milestone target date to Next Release
Fetches the most recent published release in the current major
version series from the GitHub Releases API (e.g. "2.1.1
(2026-03-23)") and exposes it as a new "Latest Release" badge.
Also looks up the target due date of the matching GitHub milestone
(e.g. "HDF5 2.2.0") and appends it to the existing Next Release
badge when one is set. Both lookups are independent of the
project-board query and degrade gracefully to "N/A" on failure.
The H5D__chunk_lock() call has a matching H5D__chunk_unlock() in normal conditions, but it is missing when an operation fails after H5D__chunk_lock() succeeds.
The previous `lib/cmake/hdf5-config.cmake` isn't in CMake's find_package
search path since CMake expects that to be a common path with each
package having it's own subdirectory. This changes it to
`lib/cmake/hdf5/hdf5-config.cmake` so the config is now found when the
install prefix is in `CMAKE_PREFIX_PATH`.
This also sets `HDF5_USE_GNU_DIRS=ON` by default for non-Windows builds.
Fixes#6137
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
- The layout of the shared message encoding was actually decribed at the beginning of the section IV.A.2.
For clarification, the section was split into two with one section purely for the shared message encoding
and another section for the catalog of message types.
- Cross-linked shareable messages to the shared message encoding section.
- Misc. cleanup
* Avoid converting fill value from memory to file type when reading vlen
data from a nonexistent chunk.
* Committing clang-format changes
* Add Changelog note
* Spelling
* Update changelog note
* Improve test description
* Hopefully make formatter happy
* Hyphenate read-only
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Fix for issue #6430: add decription for H5Tencode/H5Tdecode to Appendix.
* Fix for issue #6392:
The fix addressed part 1 of the issue.
No change is needed for part 2 of the issue: verify that the info is already there in the Driver Info Message.
* Fix for issue #6360
* Fix for issue #6416 in section III.I. Disk Format: Level 1I - Shared Object Header Message Table.
---------
Co-authored-by: Matt L <124107509+mattjala@users.noreply.github.com>
* Add change-request and manually-added-CODEOWNER lines to review checklist
Reviewers who request changes now get their own line under each area
their inline comments touch, whether or not they're a CODEOWNER or a
requested reviewer. CODEOWNERS who are review-requested directly by a
human (rather than auto-picked) get a separate required-approval line,
and their approval is now required for that area's sign-off in addition
to the usual reviewer's.
* Prune reviewers whose area dropped out of scope
A CODEOWNER requested for an area the PR used to touch, before a later
push narrowed the diff, was never removed: touchedAreaOwners only
reflects areas touched right now, so none of the existing avalanche
pruning ever considered them. Reproduced live on PR #6528, where the
branch's diff shrank to just .github/ but gheber/fortnern/mattjala
(owners of unrelated areas) stayed as requested reviewers.
Manually-added CODEOWNERS are exempt, since a human's deliberate
request shouldn't be silently undone by a later push.
* review-checklist: fix avalanche exemption regressing genuine avalanches
#6524 exempted a review_requested login's whole area from avalanche
detection to stop a manual re-request from being undone. But a genuine
CODEOWNERS avalanche's own review_requested sub-events look identical
to that case, and one of them can survive the ready_for_review vs.
review_requested concurrency race (#6530: draft PR marked ready for
review left all 3 CODEOWNERS owners requested instead of pruning to
one, because the surviving run's action was one of the avalanche's own
review_requested events, exempting the whole area).
Replace the exemption with a forced pick: the directly-requested login
still always survives, but now by replacing the rest of that area's
avalanche instead of exempting the area from pruning — so a genuine
avalanche still collapses to one person. Also gate justRequestedLogin
on !isBotSender, matching updatedManuallyAdded's existing reasoning
just above it: the bot's own requestReviewers calls fire this same
event and aren't a human decision.
* bound SOHM list decode to list_max messages
* Add tsohm test for out-of-range SOHM list message count
Create a file with a shared-message list index, corrupt the on-disk
message count so it exceeds list_max (repairing the table checksum),
and confirm reopening rejects the file instead of overrunning the
list image buffer and message array.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
* ROS3 VFD block cache feature
Implements a minimal I/O block cache for files without paged allocation
enabled to better optimize I/O and reduce requests to S3
I/O is cached in fixed-size blocks (16MiB blocks by default) and are kept
in a simple LRU cache that evicts the oldest used block when a new block
needs to be cached
Reading and caching of the initial bytes of a file has been delayed
from file open to the first read for a file instead
API functions have been added for setting/getting the I/O block caching
parameters to be used
* Address comments from review
* Rename 'page' -> 'block'
* Change default block cache size and separate from page buffer logic
* Update CHANGELOG
* Fix for issue #6430: add decription for H5Tencode/H5Tdecode to Appendix.
* Fix for issue #6392:
The fix addressed part 1 of the issue.
No change is needed for part 2 of the issue: verify that the info is already there in the Driver Info Message.
* Fix for issue #6360
---------
Co-authored-by: Matt L <124107509+mattjala@users.noreply.github.com>
A direct review_requested (e.g. manually re-requesting a reviewer via
the GitHub UI) adds a second currently-requested owner to that
reviewer's area — indistinguishable from an unpruned CODEOWNERS
avalanche, so the avalanche-detection pass immediately removed them
again on the same run. Carve out the login this run's review_requested
action names before running avalanche detection.
* ci: skip draft-pr-policy checkout on issue-only comments
The issue_comment event fires for comments on both issues and PRs;
draft-pr-policy only cares about PR draft-staleness, so short-circuit
before checkout when the comment is on a plain issue. Also switch all
three jobs to a sparse, shallow checkout since they only need
.github/scripts to load the github-script payload.
* ci: also skip draft-pr-policy on bot-authored PR comments
draft-pr-policy.js already excludes Bot comments when deciding whether
a draft was revived, so a bot comment (e.g. review-checklist posting
its checklist) can never do anything meaningful here — it still ran
checkout + API calls only to no-op. Filter it out at the same if:
using the free github.event.comment.user.type field.
* ci: skip checkout for draft-pr-policy on non-draft PR comments
Even after filtering out issue-only and bot comments, a human comment
on any non-draft PR still paid for a full checkout just to have the
script itself discover pr.draft is false and return. Add a cheap
pulls.get-only pre-check step (no checkout required) and gate the real
checkout + script load on its result.
* Fix for issue #6430: add decription for H5Tencode/H5Tdecode to Appendix.
* Fix for issue #6392:
The fix addressed part 1 of the issue.
No change is needed for part 2 of the issue: verify that the info is already there in the Driver Info Message.
These workflows use pull_request_target / workflow_run with elevated
permissions (pull-requests: write, issues: write). Because GitHub
copies workflow files into forks, any fork with Actions enabled was
independently running these privileged workflows against its own
PRs, e.g. https://github.com/sp26-hdfgroup/hdf5-sandbox/pull/2.
Add the same github.repository == 'HDFGroup/hdf5' guard already used
in review-checklist-test.yml so the job-level if short-circuits
before doing anything in a fork's copy of the workflow.
actions/checkout v7.0.0 (bumped in #6500) added a blanket check that
blocks checkout on pull_request_target/workflow_run events, even when
no fork ref is checked out. This workflow only ever checks out the
base branch (develop), so opt in via allow-unsafe-pr-checkout.
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
For objects with multiple hard links, use hash table to map between
object tokens and pathnames during traversal to avoid linear scan over
all previous objects for each hard link seen
Use separate hash table for h5trav "table" interface to map between
object tokens and an index into the table of visited objects. This
facilitates quick lookups of objects when adding hard link name aliases
for h5repack processing
* Fix H5DreadVL failing for pre-allocate cmpd-of-seq dsets
* Fix bad vlen of cmpd with null slot read
* Fix bad cmpd of cmpd read in java
`translate_rbuf`'s H5T_VLEN case had a similar bug where when `found_jList` was set to false due to an entyr in `ret_buf` being null, `ret_buf.add()` would be invoked on an array of objects without the list .add() method. This would occur whenever a read was invoked of a vlen sequence with a null (non-preallocated) entry. The pre-existing tests only tested the pre-allocated cases.
I removed the use of the `found_jList` flag, since it conflated the passing of an unallocated slot with `ret_buf` not being an array. Instead use `ret_buflen == 0` as the check to match the pattern in H5T_INTEGER and other branches.
The test for this fix is testH5Dread_vlen_of_compound_nullslot.
---
`translate_atomic_rebuf` had two issues related to handling of nested compounds. First, it discarded recursive returns, resulting in the construction of empty lists. Secondly, its member offset (`char_buf + i * typeSize + memb_offset`) was incorrect. In this case, `i` was the member index and `memberSize` was the entire cmpd size, so the offset would be erroneously large. It seems like this came from copying of the offset computation from `translate_rbuf`, which had to advance over entire elements of compound data. This error was duplicated on the write side in `translate_atomic_wbuf`'s H5T_COMPOUND case (h5util.c:4611).
I changed `translate_atomic_rbuf` to capture the resultant object, and dropped the `i * typeSize` term in both routines.
The new test verifying the fix works is `testH5Dread_vlen_of_nested_compound`.
* Add exception checks
* Update NULL checks in translate_wbuf
* Correct potentially bad array length check
* Clang format
* Fix readVL/writeVL crash on malformed buffer
* Committing clang-format changes
* Add bufSize checks to wbuf/rbuf translation
* Remove vlen pre-allocation support
* Harden JNI buffer interface
* Handle opaque types as byte[] and document JNI buffer data model
Opaque elements were grouped with H5T_INTEGER in the nested-type
translation path, which boxed them as Integer/Long and rejected
arbitrary-sized opaque blobs. Treat H5T_OPAQUE like H5T_REFERENCE
(a byte[] per element) in translate_atomic_rbuf, translate_atomic_wbuf,
and h5validate_atomic_wbuf so nested opaque round-trips correctly.
Also add "Buffer data model" header comments on translate_rbuf() and
translate_wbuf() and note the reference/opaque byte[] leaves in the
H5.java javadocv.
* Initialize typeSize to fix -Werror=maybe-uninitialized
typeSize was assigned only inside the vl_data_class branch but read in
a second, separate vl_data_class branch, which gcc -O2 flags as
maybe-uninitialized under -Werror. Initialize it to 0 at declaration in
H5Aread/H5Awrite/H5Dread/H5Dwrite, matching the existing vl_array_len
pattern.
* Port nested cmpd/vlen tests to java/test and sync reference
The legacy java/test tree's JUnit-TestH5D.txt reference listed the new
nested compound/vlen tests, but the corresponding @Test methods existed
only in java/src-jni/test/TestH5D.java. Port the 10 tests and the
writeCompoundOfVlenDataset helper into java/test/TestH5D.java, remove
debug prints, and
regenerate the reference to match the actual JUnit output.
* Support nested vlen/compound datatypes in Java FFM compat layer
The FFM compatibility layer (java/hdf) lacked the vlen/compound read and
write support that the JNI interface gained, so the nested cmpd/vlen tests
ported into java/test (TestH5D) failed and leaked an id.
VLDataConverter now has recursive encodeValue/decodeValue helpers that pack
and unpack any member class (integer, float, fixed/vl string, nested
compound, and VLEN) in the native HDF5 in-memory layout. These are wired
into convertCompoundDatatype, readCompoundDatatype and convertRawDataToArrayList,
and a type-aware convertToHVLAuto handles top-level VLEN-of-compound writes.
Compound reads now reclaim VL memory, and type/count mismatches raise
IllegalArgumentException instead of silently corrupting data.
H5DwriteVL rejects an undersized buffer up front and routes VLEN writes
through convertToHVLAuto. The JUnit-TestH5D reference regains its trailing
blank line to match the actual JUnit output.
* Committing clang-format changes
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
- action's hash pin has mismatched or missing version comment
- credential persistence through GitHub Actions artifacts: does not set
persist-credentials: false
A declared cd_nelmts with no values following it (e.g. UD=<filtn>,<flag>,1)
was never committed to filt->cd_nelmts: the trailing token (no comma after
it) was always treated as a value, never checked against the l/f/p pending
flags the way the comma-triggered branch does. h5repack's own validation
then silently passed since cd_nelmts stayed at its default 0, and the
mismatch was only ever caught by coincidence when the underlying filter
plugin did its own internal cd_values check (issue #6462).
Commit the trailing token to whichever UD field is still pending, mirroring
the comma-triggered branch exactly.
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
The HDF-EOS5 compatibility test downloads a source tarball from
git.earthdata.nasa.gov, an external host that has proven unreliable and
frequently times out, causing spurious PR-check failures unrelated to the
code under review.
Move the test off the pull_request/push triggers onto a daily schedule
(plus workflow_dispatch) so transient network failures no longer block PR
merges, while still catching genuine HDF-EOS5 regressions on a daily
cadence. Guard the job with an owner check so it does not run on forks.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Fix runExecute.cmake: restore ERROR_APPEND and fix zero-or-more mask patterns
Three bugs were introduced when runTest.cmake was refactored into runExecute.cmake:
1. ERROR_APPEND=1 support was dropped. Tests that redirect their error-stack
output to stderr and rely on ERROR_APPEND to combine it with stdout before
comparison (e.g. H5TEST-err_compat, H5TEST-error_test) fail silently because
the reference file never matches the truncated actual output.
2. " line [0-9]*" uses zero-or-more digits, so it matches " line " (with zero
digits) in already-masked reference text like " line (number)", prepending
another "(number)" and producing " line (number)(number)".
3. "HDF5 [1-9]*[.][0-9]*..." has the "HDF5 " prefix and uses [1-9]* (zero-or-
more), so it does not match "2.2.0" in actual output (blocked by the leading
"("), and double-masks "version (number)" in the reference.
"H5Eget_auto[1-2]*" / "H5Eset_auto[1-2]*" have the same zero-or-more issue,
double-masking "(1 or 2)" already present in reference files.
Fix: restore ERROR_APPEND handling; change * to + for all digit/char class
quantifiers that can match zero occurrences in already-masked reference text;
remove the "HDF5 " prefix from the version pattern. Same fix applied to
HDF5Examples/config/cmake/runExecute.cmake which has identical bugs.
* Fix AOCC CI: source setenv_AOCC.sh from its actual install location
install.sh generates setenv_AOCC.sh inside the aocc-compiler-VERSION/
directory (where it runs from), not in the repo root one level up.
* Fix AOCC CI: replace hardcoded runner paths with GITHUB_WORKSPACE
All /home/runner/work/hdf5/hdf5/ paths were hardcoded to the HDFGroup/hdf5
repo name. Running the workflow in any fork (e.g. brtnfld/hdf5_swmr_2)
puts the checkout under a different path, breaking AOCC/OpenMPI install,
configure, and build steps. Use $GITHUB_WORKSPACE / ${{ github.workspace }}
so the paths resolve correctly regardless of repo name.
* fix(aocc): source setenv_AOCC.sh from workspace root, not compiler subdir
install.sh places setenv_AOCC.sh in the workspace root, not inside the
aocc-compiler-X.X.X/ directory.
* Fix runExecute.cmake: anchor HDF5 version regex to full token
Replace the over-broad version pattern with one that matches the complete
'HDF5 (x.y.z)' token, preventing over-matching of IP addresses and other
version-like strings, and avoiding nested substitution artifacts in .err
reference comparisons. Applied identically to both copies of the file.
Three distinct but related bugs caused the review-checklist bot to
@ mention more reviewers than intended.
**Bug 1 — bot-sender guard (sticky exclusion)**
The bot's own removeRequestedReviewers API calls fire
review_request_removed events that self-trigger the workflow. Without a
guard, that self-triggered run treated its own bookkeeping removal as a
deliberate human decision and added the login to the persisted
exclusion set permanently. Fix: check sender.type === 'Bot' and skip
the exclusion update for bot-originated removals.
**Bug 2 — cancel-in-progress race on opened/ready_for_review**
GitHub fires one review_requested event per CODEOWNERS auto-assigned
owner; each triggers a workflow run. With cancel-in-progress, the
surviving run may be a review_requested rather than the opened event,
bypassing the avalanche-prune branch entirely and leaving all CODEOWNERS
requested. Fix: track hasExistingComment as a proxy for "first
coordination pass" — if no checklist comment exists yet, prune regardless
of which action survives the race.
**Bug 3 — per-area avalanche on synchronize (PR #6484)**
GitHub's CODEOWNERS engine re-fires when a commit first touches a new
CODEOWNERS-covered area, not only on PR open but also on synchronize.
The surviving run fell through to additive fill, saw the area as
"already has owners, skip", and listed all auto-assigned CODEOWNERS.
Fix: before the synchronize-swap and additive-fill paths, detect any
area whose owner-list ∩ existingRequested > 1 (per-area avalanche) and
prune that area to the single load-balanced pick.
84 tests (was 82).
* Fixes for issues: #6448, #6449, #6444
* Fix for issue #6443.
* Fix for issue #6365.
* Fix spelling error.
* Modifications based on PR review comments.
* Correct spelling error.
* Replaced 3 duplicate field descriptions with cross-reference to the version 3 layout message.
* Refactor the description for the layout message regarding the dimension related fields.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
* ci: replace actions/stale with bot-aware mark-stale script
actions/stale uses updatedAt to measure inactivity, so any bot event
(e.g. the /remove-reviewer acknowledgment comment) resets the stale
countdown even when there has been no meaningful human activity for
months. PR #6332 was last touched by a human on 2026-04-02 but was
not flagged because a reviewer-removal on 2026-06-11 refreshed the
timestamp.
Replace the actions/stale step with a custom mark-stale.js script
(same pattern as alert-stale.js) that only counts non-bot comments,
non-bot review submissions, and commits as meaningful activity. The
script also removes the stale label if such activity occurs after the
label was applied.
* ci: fix draft-stale keepalive for external contributors
Two bugs with the keepalive checkbox on draft-stale PRs:
1. External contributors (fork authors) lack write access to edit the
bot's comment, so clicking the checkbox silently fails for them.
Fix: also treat a new non-bot comment posted after the keepalive
comment as a sufficient keepalive signal.
2. The stale label could take up to 24 hours to be removed (daily cron
only). Fix: add an issue_comment.created trigger so draft-pr-policy
fires immediately when someone comments on a stale draft PR.
mark-stale and alert-stale are guarded to only run on
schedule/workflow_dispatch, not on every comment.
Also fix lastRealActivityAt to exclude bot comments (matching
mark-stale.js), so the keepalive and "Thanks for confirming" bot
comments don't count as real activity when measuring staleness.
* fix(review-checklist): re-request dismissed reviewer on fixup push
When a new commit dismisses a prior reviewer's approval, GitHub's
CODEOWNERS engine auto-assigns a fresh (possibly different) owner for
the changed area. The synchronize handler now detects dismissed
area-owners and swaps them back in, removing the fresh CODEOWNERS pick.
Adds planSynchronizeSwaps() pure helper (exported) with 7 unit tests
covering the PR 6475 scenario and edge cases.
* fix(review-checklist): don't remove a fresh pick still needed by another area
planSynchronizeSwaps could remove a fresh CODEOWNERS pick to restore a
dismissed reviewer even when that pick also covered a different,
unrelated touched area — removeRequestedReviewers strips them from the
whole PR, silently uncovering the other area. Now skips removal when
the candidate owns any other touched area.
Also dedupes the consuming loop so a login needed by two areas isn't
requested/removed twice.
5 new tests covering the cross-area guard and its boundaries.
* fix(review-checklist): don't let bot's own reviewer removal create a sticky exclusion
The bot's own removeUnselected/removeRequestedReviewers calls (draft-opened
CODEOWNERS cleanup, stale-exclusion enforcement) fire review_request_removed,
which the workflow also listens on — self-triggering another run. That run
previously read its own bookkeeping removal as a deliberate human decision
and added the login to the persisted exclusion set, permanently blocking
that owner from ever being auto-assigned to the PR again. Guard on
sender.type !== 'Bot' so only human-driven removals become sticky.
* fix(review-checklist): prune CODEOWNERS avalanche regardless of which event wins the race
GitHub's CODEOWNERS engine fires one review_requested event per auto-assigned
owner on PR creation, and each re-triggers this workflow. With concurrency:
cancel-in-progress, whichever run starts last wins — and that's just as
likely to be one of those review_requested runs as the opened run itself.
A surviving review_requested run fell through to the additive-fill branch,
saw every area already "covered" by the avalanche, and pruned nothing.
This hit PR #6479 itself: all 4 CODEOWNERS for .github/ stayed requested.
Branch on whether a checklist comment exists yet instead of which action
survived — that signal is race-resistant: no comment means this is the PR's
first coordination pass no matter which event got here. Threads
hasExistingComment through from run() (defaulting to true, i.e. additive-fill,
on a comment-fetch failure so an API hiccup can't be mistaken for a fresh PR).
2 new tests: the #6479 race itself, and a contrast case confirming a routine
review_requested on an already-established PR still uses additive-fill.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
pr.updated_at is bumped by metadata-only changes (reviewer
requested/removed, labels, milestone, assignee), letting an
abandoned draft dodge the staleness check indefinitely. Use the
latest commit/comment/review/review-comment timestamp instead.
bmribler
Scot Breitenfeld
vchoi-hdfgroup
Larry Knox
Neil Fortner
Mark Kittisopikul
Chuck AtkinsandLarry Knox
jhendersonHDF
Gerd Heberandgithub-actions