Library: preserve concurrent changes during conditional save and move

Ouverte
  • Quelque chose ne va pas ?
#480 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
backend, databases, testing

Piste de recherche

Read elastos/crates/elastos-server/src/library.rs around the conditional write (develop line 3704) and move path (line 6630), plus api/gateway_provider_proxy.rs around lines 439–448 and 802–811. Start by tracing how revision checks and mutation ownership work across the Library and object-provider processes. Done means deterministic conflict tests cover concurrent writes, move/upload, and copy/destination creation, with acknowledged data preserved and destination failures leaving the source intact; the issue also calls for installed Mac and Linux checks and independent review.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

User impact

A Library operation can overwrite a newer save or remove newer source bytes while reporting success. This is a proposed 0.8.0 release-blocking data-integrity finding from the systematic review in #93. Source review confirms the race; installed reproduction and its frequency remain unmeasured.

Source evidence

Checked on fetched develop 3beb816438fd567145a8d725e22465bd83277cf0 and local release candidate 460b1888d344f52cebd1c25866be88ff4085f035. Two independent reviewers and the lead checked the call path.

  • In published develop, Library conditional write checks the expected revision before calling the unconditional protected-object writer at line 3718. Candidate equivalents are library.rs:3774,3789.
  • The protected-object writer acquires its mutation lock after that check. Two callers can both accept revision R and then both save, so one acknowledged change is lost.
  • Candidate library.rs:7194-7206 reads a source, writes the destination, then removes the source. An upload between the read and removal can be acknowledged and then lost. The develop equivalent starts at line 6630.
  • Ordinary object-provider messages are serial, but gateway raw upload and chunk completion call the Library write path directly (api/gateway_provider_proxy.rs:439-448,802-811). That path can overlap the separate object-provider process. The auth mutation mutex is process-local.
  • Documents already holds a mutation guard across its revision check and write. Library needs one ownership boundary that also covers its gateway/provider split.

Smallest repair and proof

Keep user-visible operation semantics. Make revision validation and commit one operation. Give move/copy explicit source and destination ownership, and preserve a newer source version if another writer changes it. A lock confined to only one process is insufficient for the current paths.

  • A deterministic write/write test admits only one request using the same old revision; the other receives a conflict.
  • Move/upload and copy/destination-create tests preserve all acknowledged data and report a clear conflict.
  • Destination failure leaves the original source intact.
  • Exercise gateway upload together with the external object-provider path.
  • Installed Mac and Linux checks cover two concurrent clients and restart/recovery.
  • Independent review and exact-candidate acceptance are recorded before closure.

Deduplication: #450 covers opening/lazy protection, #445 listing, #449 extraction, and PR #428 UI behavior. This issue owns mutation atomicity. Searches of open and closed issues found no matching owner. This issue is queued for release triage; the audit started no implementation work.

Langage dominant
Rust
Étoiles
6
Forks
2
Merge moyen
1 j 3 h
PR mergées (30 j)
42

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de elastos/elastos-runtime

Toutes les issues de elastos/elastos-runtime

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.