Fix amendment lookup dropped by publication-date filter (#181)

[andrew2net]

Problem

Fixes #181. Citing a draft amendment such as ISO 32000-2:2020/DAM 1 from Metanorma logs Not found and renders [NO INFORMATION AVAILABLE], even though relaton fetch "ISO 32000-2:2020/DAM 1" returns full XML on the same machine.

Root cause

Amendments, corrigendums and supplements carry no year on their own pubid identifier — the year lives on the underlying standard (pubid.root.year, e.g. 2020):

ISO 32000-2:2020/DAM 1  ->  pubid.year = nil,  pubid.root.year = 2020

When a publication-date filter is active, Bibliography.get routes through find_match_by_date → year_in_range?, which begins with return false if year.zero?. For these references hit_year resolved to 0 (own year nil, index :year absent), so they were excluded from every date-filtered query — regardless of the filter year (verified across 2019–2026, all "Not found").

This only surfaces inside Metanorma because Metanorma derives a publication-date filter from the citing document's :copyright-year: / :created-date: attributes. relaton fetch passes no such filter, which is why the CLI worked. Reproduced end-to-end with Peter's mn-playground build on macOS; removing only those two attributes from the document flips the result to Found.

Not a pubid-version, platform (Windows/Ruby 4), or stale-index issue — all ruled out.

Fixes

1. Year fallback (hit_year). Fall back to hit.pubid.root.year when the identifier's own year and the index :year are both absent. root walks the full base chain (handling nested supplement / corrigendum-of-amendment), unlike base which climbs only one level.

yr = hit.pubid&.year || hit.hit[:year] || hit.pubid&.root&.year

2. Robustness guard (fetch_and_check_date). The year fix lets amendments reach fetch_and_check_date. If the index references a data file that 404s, hit.item returns an item with no docidentifier and the method crashed on ret.docidentifier.first.content. Guard against it so the candidate is skipped and the lookup degrades to "not found" instead of raising.

Tests

• "finds an amendment whose year lives on the base" — date filter + iso_32000_2_2020_dam_1 cassette; fails before fix (nil), passes after.
• "returns nil instead of raising when the data file fails to load" — locks the robustness guard.
• Full bibliography_spec.rb suite green.

Note on upstream data

While verifying end-to-end I found the relaton-data-iso v2 data files for this amendment (data/iso-32000-2-2020-dam-1.yaml) currently 404, after automated "update documents" commits on 2026-06-12 — the index still lists them. That's a separate data-side inconsistency; with the data present (as in the recorded cassette) this fix resolves the reference fully, and with it absent the second commit makes the lookup degrade cleanly instead of crashing.

🤖 Generated with Claude Code

[ronaldtse]

@andrew2net The comment here is wrong:

Amendments, corrigendums and supplements carry no year on their own pubid identifier — the year lives on the underlying standard (pubid.root.year, e.g. 2020)

A DRAFT Amendment/Corrigendum may or may not have a year attached.

• "ISO 32000-2:2020/DAM 1" as undated form is valid -- this happens when the project stage of DAM is registered, but the document is not yet published.
• "ISO 32000-2:2020/DAM 1:2026" as dated form is valid -- this happens when the project stage of DAM is registered AND the document is published.

An Amendment/Corrigendum/Supplement may or may not have a year attached.

• "ISO 32000-2:2020/Amd 1" as undated form is valid, just like any other ISO document.
• "ISO 32000-2:2020/Amd 1:2026" as dated form is valid, just like any other ISO document.

[andrew2net]

@ronaldtse thanks for clarifying. This raises the following questions:

• should we use base or amd/corr year in filtering when both years are attached?
• if only one year attached, base or amd/corr, should the filter use any of them?