Bucket.Attrs never returns ReplicationConfig: replication configuration is write-only

Aperta Adatta ai principianti
  • Qualcosa non va?
#91 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #87 di @ffumero2003 — chiusa senza merge

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
api, backend

Direzione di ricerca

Leggi base/base.go listBuckets e b2/baseline.go attrs(), quindi confronta attrs() con la mappatura di scrittura esistente in updateBucket. Aggiungi un test senza rete che simuli b2_list_buckets con una configurazione di replica e verifichi che l’ID della chiave sorgente e i campi della regola compaiano in Attrs; verifica inoltre che un bucket senza la configurazione restituisca nil. Il lavoro è completo quando entrambi i casi passano.

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

Descrizione

bug

Summary

blazer can set a bucket's replication configuration but never reads it back.
(*Bucket).Attrs returns everything else about a bucket — lifecycle, info, type, file
lock, CORS, default SSE, default retention — but not ReplicationConfig, so
bucket.Attrs(ctx).ReplicationConfig is always nil even after a successful update. The
replication-config capability is effectively write-only: a caller can configure
replication but cannot read the configuration back through the SDK to confirm it, drive a
read-modify-write, or disable a rule based on current state. Affected: current
master.

Where it is (two gaps, both must be fixed)

  1. base/base.go listBuckets parses the replicationConfiguration field from the
    b2_list_buckets response but never assigns it to the constructed Bucket, so
    b.b.ReplicationConfiguration stays nil regardless of what B2 returned.
  2. b2/baseline.go attrs() has no mapping from the internal replication config to the
    public BucketAttrs.ReplicationConfig, so even if (1) were fixed the value would not
    reach the caller.

Fixing only one of the two leaves ReplicationConfig nil — the value has to be both
retained off the list response and mapped onto the public attrs.

Expected vs actual

After (*Bucket).Update sets a replication configuration, a subsequent Attrs(ctx)
should return a non-nil ReplicationConfig carrying the source application key id and
every rule field (destination bucket id, file-name prefix, priority, rule name,
enabled/include-existing flags). Today it returns nil in every case, including immediately
after a confirmed successful update.

Fix direction

  • base/base.go: have listBuckets carry bucket.ReplicationConfiguration.Value onto the
    constructed Bucket.
  • b2/baseline.go: map b.b.ReplicationConfiguration → BucketAttrs.ReplicationConfig
    (source key id plus every rule field) in attrs(), nil-guarded. This is the inverse of
    the existing write mapping already present in updateBucket.

Public API is unchanged — this only populates an existing field that was always nil.

Verification

A network-free test that stubs b2_list_buckets to return a bucket with a
replicationConfiguration and asserts Attrs surfaces the source key id and the rule
fields, plus a negative case confirming a bucket without one yields a nil
ReplicationConfig.

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.