docs(assets): ratify ruling-6 — upload dedup runs in both hashing modes

The prior wording ('only hash mode permits upload deduplication') never
described the code. upload_from_temp_path hashes unconditionally and
lookup_for_upload_dedup never consults mode.hashing_enabled (unlike
lookup_for_from_hash, which does) — the deliberate product decision from
4bced38a. Only scanner/output hashing is gated by --enable-asset-hashing.

Ruling text updated to match; no behaviour change.
This commit is contained in:
Simon Pinfold
2026-08-26 19:14:34 -07:00
parent 29410e4eb7
commit 002c1d7ae8

View File

@@ -252,15 +252,16 @@ def test_scenario_5_rename_always(session):
def test_scenario_6_upload_dedup(session, tmp_path):
"""Ruling 6: only hash mode permits upload deduplication.
"""Ruling 6: upload dedup runs unconditionally in both hashing modes; only
scanner/output hashing is gated by ``--enable-asset-hashing``.
STALE RULING — flagged, not rewritten. Uploads hash unconditionally
(``upload_from_temp_path`` calls ``_snapshot_hash_with_retry`` before it
consults anything, and ``lookup_for_upload_dedup`` never asks
``mode.hashing_enabled``), a deliberate product decision made in 4bced38a.
So dedup is available in BOTH modes and the ruling above no longer
describes the code. The test pins what actually ships; the ruling text needs
an owner's decision, so it is left untouched.
Ratified 2026-08-26, superseding the earlier "only hash mode permits upload
deduplication" wording, which never described the code. Uploads hash
unconditionally — ``upload_from_temp_path`` calls
``_snapshot_hash_with_retry`` before it consults anything, and
``lookup_for_upload_dedup`` never asks ``mode.hashing_enabled`` (unlike
``lookup_for_from_hash``, which does). That is the deliberate product
decision made in 4bced38a, so dedup is available in BOTH modes by design.
"""
(tmp_path / "output").mkdir(parents=True)
payload = b"the-uploaded-bytes"