Support daysFromStartingToCancelingUnfinishedLargeFiles and preserve it across Attrs and Update

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

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend

Direzione di ricerca

Start with b2/b2.go for LifecycleRule, then trace lifecycle conversion through b2/baseline.go, base/base.go, and internal/b2types/b2types.go; inspect x/consistent/consistent.go for the save path. Add coverage using an HTTP fake for the Attrs/Update round trip and for setting the field through NewBucket and Update. Done means every lifecycle field survives the round trip and consistent saves preserve rules.

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

Descrizione

bug enhancement

Summary

B2 lifecycle rules have a fourth field, daysFromStartingToCancelingUnfinishedLargeFiles, which is the server-side way to clean up unfinished large files. blazer's LifecycleRule (and the base and b2types types under it) does not have it, so:

  1. blazer users cannot set this rule.
  2. The documented update pattern (Attrs, modify, Update; see the docs on Bucket.Update and IsUpdateConflict) rewrites lifecycle rules from blazer's partial copy and drops the field from rules configured elsewhere (web console, CLI, other SDKs). x/consistent does this on every save.

Unfinished large files are a normal outcome in blazer (a writer that fails without WithCancelOnError, a process that exits mid-upload). Their parts are stored and billed until cancelled, so silently removing the cleanup rule changes the bucket's storage costs without any signal.

Current behavior

At a5e0d13:

  • b2/b2.go:375-387: LifecycleRule has Prefix, DaysNewUntilHidden, DaysHiddenUntilDeleted.
  • b2/baseline.go:519-527 (attrs), :399-411 (updateBucket) and :253-260 (createBucket) copy those three.
  • base/base.go:773-777 and internal/b2types/b2types.go:83-87 define the same three, so the field is dropped on decode.
  • b2/baseline.go:395-411: since merged Backblaze/blazer#78, Update sends rules only when LifecycleRules is non-nil, but Attrs returns a non-nil slice whenever the bucket has rules, so an Attrs/Update round trip always rewrites them.
  • x/consistent/consistent.go:321-325: save writes Attrs back with Update.

Reproduced locally against an HTTP fake: b2_list_buckets returned a rule with daysFromHidingToDeleting: 1 and daysFromStartingToCancelingUnfinishedLargeFiles: 7; Attrs, adding one bucket-info key, and Update sent:

"lifecycleRules":[{"daysFromHidingToDeleting":1,"fileNamePrefix":""}]

A rule that only cancels unfinished uploads comes back as {"fileNamePrefix":""}.

Expected behavior

Callers can set the rule, and an Attrs/Update round trip keeps every lifecycle field it read.

Proposed change

  1. Add the field (for example DaysUnfinishedUntilCanceled int) to b2.LifecycleRule, base.LifecycleRule and b2types.LifecycleRule with omitempty, and copy it in createBucket, attrs, updateBucket and the base decode paths.
  2. Keep the raw lifecycle JSON from the last read and send it back unchanged when the caller did not modify LifecycleRules, so future fields survive.
  3. Mention the rule in the Writer docs next to WithCancelOnError and Resume.

Acceptance criteria

  • Attrs then Update sends back every lifecycle field received (HTTP fake).
  • NewBucket and Update can set the new field, and Attrs returns it.
  • x/consistent save preserves a bucket's lifecycle rules exactly.

Related

Open Backblaze/blazer#108 is a separate updateBucket defect. Merged Backblaze/blazer#78 fixed sending an explicit empty rule list and stopped Update sending rules when LifecycleRules is nil; it did not add the field.

Lingua principale
Go
Stelle
66
Fork
18
Merge medio
1g 10h
PR unite (30g)
132

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 Backblaze/blazer

Tutte le issue di Backblaze/blazer

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.