Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

The store commits a backfilled older observation as the newest, and an id-less build erases a recorded identity

Aperta
  • Qualcosa non va?
#41 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 9 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, databases

Direzione di ricerca

Start with commit() and _identity_problem, then read history-and-reports.md and the HISTORY-PUBLISH-06 contract. Trace how a backfilled bundle updates the index, project location, identity fields, and latest/; also check how offline builds handle missing IDs. Done when older observations preserve the current tail and recorded identity, with tests covering the reproduced history-gap cases.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Found by the review of 2026-09-30. Both are about what commit() does with a bundle that is not the new tail, and both are reproduced against a real store written by the current code.

1. An older observation is committed as if it were the newest

Since #17 an observation that is not later than the previous bundle is INCOMPARABLE (NON_MONOTONIC_OBSERVATION) and claims no direction; where such a bundle lands was left to the monotonic-write policy of #12 finding 6. Today it lands everywhere a newest bundle does, because commit() always relocates the project, overwrites the index header and republishes latest/:

  • the index stays sorted, so its tail is still the newer bundle, but latest/ now holds the older one: index tail: 9ec829e6e113, latest/ copy bundle: a45db0c70eab (older);
  • the fleet entry names the tail (bundle_id 9ec829e6e113, observed 2026-09-05) and links …/latest/report.md, which says Observed at: 2026-09-01T12:00:00Z, Comparison: INCOMPARABLE: the fleet README and the observe-self job summary show the older report as current;
  • after a compaction of the index (which the contract allows), the next run is HISTORY_GAP (latest pointer a45db0… differs from index tail 9ec829…), where the same run without the backfill is COMPARABLE;
  • a backfill under the old name of a renamed repository moves the whole history back: after widget → gadget on 2026-09-07 and a 2026-09-06 observation backfilled under widget, the directory is github.com/acme/widget, the index project_key is widget, and once the next regular run relocates it again the genuine 2026-09-07 rename record is gone from renames.

This violates HISTORY-PUBLISH-06 ("index tail, latest view and immutable bundle mutually consistent") without anyone having decided the policy. A minimal repair that decides nothing: in commit(), a bundle becomes the tail only when its (observed_at, bundle_id) is greater than the current tail's; otherwise it is written where the project already lives, appended to the index without touching project_key, project_identity or renames, and latest/ is not republished. _report_path should use latest/ only when it holds the tail. Rejecting such bundles outright, or archiving them apart, stays the policy question of #12 finding 6.

2. A store without identities binds the tail to the current run, and an id-less commit erases a recorded id

history-and-reports.md says the tail must carry "the identity the index records (its locator, for a store without identities)". _identity_problem uses recorded or <the id of the current run> instead:

  • the first id-bearing run over a locator-keyed history is HISTORY_GAP with PROJECT_IDENTITY_MISMATCH: … belongs to project None, this history is project 42, although nothing is wrong: the history simply predates identities;
  • after one id-less commit (an offline build from observations without an id) the index's recorded id is None, the next id-bearing run is a HISTORY_GAP, and a rename of that project starts a BASELINE.

Only reachable through offline build; the live adapter always supplies an id. Repair: bind by locator whenever the index records no id, and never replace a recorded id with none.

🤖 Generated with Claude Code

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
5g 12h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di drevendev/Devostasis

Tutte le issue di drevendev/Devostasis

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.