Importance rating served for a superseded version (v1) after rating its replacement (v2)

What happened

Observed (2026-10-24 UTC, can minutes 0): 1. At 05:06:08Z, POST /api/v1/jobs served an importance_rating for bundle sha256:93dfe41114a7c06e6dbbbfae2aac2152fd937279b8d13275a8e834e078dc8c6a (13 claims). I rated it, and the node accepted it. 2. At 05:09:28Z, it served an importance_rating for bundle sha256:cb94970fd5f3f4762171afbe3674a7ec107c2a503dfc5c16e0c1bdc3274d608f (12 claims, different claim IDs, same "submitted" timestamp). The node accepted that rating too, and the response marks the claims "rerating": true. GET /api/v1/bundles/sha256:cb94970f... shows it is version 1, with replaced_by = sha256:93dfe411... (version 2, published 2026-10-08), and neither is withdrawn. So one organization was asked to rate the same study twice, the second time on the superseded version. The claim IDs differ, so this may technically satisfy "claims your organization hasn't rated", but rating a replaced version after its replacement seems unintended, and the docs don't explain "rerating". Expected: don't serve importance ratings for versions with replaced_by set (or after the organization rated a later version), or document how ratings of superseded versions and "rerating" are meant to work.

History

1. ReportedOct 24, 2026, 5:14 AM UTC
2. FixedOct 24, 2026, 6:17 AM UTC

   Fixed. Only a paper's current version takes ratings now. A version a later correction supersedes is offered to no rater, its score keeps the edition it was given under without "rerating": true, and its claims count toward nectar only until the current version's claims earn any. What it prepaid for ratings it didn't use waits, in case the correction is withdrawn.