# Erratum — draft-fossil-sparse-cone-00 §6.2
| | |
|---|---|
| **Document** | `draft-fossil-sparse-cone-00` |
| **Section** | 6.2 — Server Behavior (the form in which a cone-aware server serves a delta-stored artifact whose base is out of cone) |
| **Type** | Technical (a conforming server and a conforming client together leave a kept blob permanently unmaterializable) |
| **Status** | Applied in `draft-fossil-sparse-cone-00` (2026-10-17) |
| **Reported** | 2026-10-17 |
| **Submitter** | Dan Mestas |
| **Found via** | Tracing the clone serve path while specifying the content horizon of `draft-fossil-horizon-00`, whose keep set crosses delta chains in the common case |
## 1. Summary
§6.2 says what a cone-aware server emits (spine, in-cone nodes, in-cone
blobs) and nothing about the form. The sync protocol serves a stored
delta container verbatim, which is correct for a dense recipient because
the base always precedes its delta in a dense log. Under a cone the base
may be out of cone. The server then sends a kept blob as a delta against
a base it does not send; the recipient retains the dangling delta,
creates a phantom for the base, and §5.2 rule 3 forbids requesting that
phantom because the recipient's cone classifies it as elided. The blob
is held as bytes the recipient cannot apply, is never written, and is
re-requested every round.
## 2. Location
§6.2, after the paragraph ending "exactly as a dense clone bounds its
batches."
## 3. The reference behavior
The reference implementation's clone reply filters rids by the keep set
and serves each surviving container verbatim, full or delta. Its client,
on a dangling delta, retains the delta, deletes the target's phantom,
creates the source's phantom, and submits the source to the gimme filter,
which rejects it when the local elided set contains it. The combination
produces the stuck state above. On a cone-ignorant server the client's
own persist pass avoids it, because the base arrives densely and the
kept delta is written in full form from in-memory content; only a
cone-aware server that elides the base exposes the hole.
## 4. Impact
Observable and permanent for the session. A path cone whose kept files
have out-of-cone delta bases produces blobs that never land. For a
temporal cone the case is the common one: a kept tip blob's base is
almost always an older version of the same file, which the horizon
elides.
## 5. Correction
§6.2, new final paragraph:
```diff
server MUST bound the per-round walk exactly as a dense clone bounds
its batches.
+
+ A stored artifact may be held as a delta against a base, and a dense
+ reply serves such a container verbatim because a dense recipient
+ holds the base. A cone-scoped recipient may not: a kept blob whose
+ base is out-of-cone would arrive as a delta whose source the
+ recipient's own policy elides and never requests (Section 5.2), a
+ blob it holds the bytes of and can never materialize. A cone-aware
+ server MUST NOT serve a delta whose base is outside the keep set it
+ computed for the request; it serves that artifact in full form. The
+ test is a keep-set lookup per served delta; reconstruction is paid
+ only for the deltas that cross. A recipient MUST treat a phantom
+ that a retained delta names as its source as a transit phantom
+ whatever its cone classification, so that a server predating this
+ rule costs bandwidth and never a stuck artifact.
```
## 6. Rationale
Two MUSTs, one per side, because either side alone leaves a window: a
corrected server against an old client is fine, an old server against a
corrected client costs one extra fetch, and only both uncorrected get
stuck. The server rule is placed where the serve path is specified and
keeps the verbatim path for every non-crossing delta, so a dense clone
is unaffected. The client rule is a refinement of §5.2 rule 3, stated
here beside the behavior it guards rather than as an exception in §5.2,
because its trigger is a transfer event.
## 7. Verification
- Source: the reference implementation's clone reply now tests each
delta's base against the keep set and reconstructs the crossing ones;
its gimme scan keeps a retained delta's source eligible. Unit tests
pin the full-form card on the wire, the clone client's materialized
blob with the base absent, the untouched verbatim path when both ends
are kept, and the client-side request for an elided source that a
retained delta needs, beside the silence for an elided phantom nothing
depends on.
- Dependent text: `draft-fossil-horizon-00` §4.2 and §6.2.1 state the
same two rules for the temporal cone and cite this section.