validate an explicit providerId before uploading

Aperta
  • Qualcosa non va?
#1,062 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
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
blockchain, typescript
Ambito
backend-api-design

Direzione di ricerca

Start at StorageContext.resolveByProviderId and trace the explicit provider selection path through upload and data set creation. Check how the SDK reads provider activity, PDP product, service eligibility, and maximum piece size, then look for tests around provider resolution and upload ordering. Done means each detectable check fails before bytes are uploaded with a useful error and tests; the issue leaves Curio-side record keeper validation and the create-before-upload fallback open.

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

Descrizione

Problem

When a caller passes an explicit providerId, StorageContext.resolveByProviderId only checks that the provider exists in the registry. It doesn't check that the provider will accept this service or the piece size before the upload starts, so a mismatch only shows up at commit time, after all the bytes are already uploaded.

Seen on calibration while testing large pieces with filecoin-pin migrate --provider-id 36: a 22 GiB piece uploaded and parked on SP 36 (about 70 minutes), then data set creation failed with:

Failed to create data set. Details: Service Provider PDP
recordKeeper address not allowed for public service

Other SPs failed late in similar ways: SP 42 returned 413 on a direct upload behind Cloudflare, and SP 49's storage write failed at 15 GiB.

Proposal

Before uploading to an explicitly chosen provider, fail fast with a clear error when the provider can't take the job:

  • the provider is active and has a PDP product
  • the provider is usable for this Warm Storage service (approved, or whatever FWSS requires for data set creation on that network)
  • the piece size fits the provider's advertised max piece size

Open question: the SP 36 rejection is a Curio-side setting (allowed record keepers), so it may not be visible on chain. If there's no cheap way to detect it up front (an SP endpoint, or creating the data set before uploading the bytes), the fallback is to create the data set first and upload after.

Done when

  • explicit providerId is validated before any bytes are uploaded, with a test per check
  • the error says which check failed and how to pick another provider
Lingua principale
TypeScript
Stelle
28
Fork
35
Merge medio
2g 4h
PR unite (30g)
44

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 FilOzone/synapse-sdk

Tutte le issue di FilOzone/synapse-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.