Library: preserve concurrent changes during conditional save and move

Offen
  • Stimmt etwas nicht?
#480 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
backend, databases, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
6
Forks
2
Ø Merge
1 T. 3 Std.
Gemergte PRs (30 T.)
42

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus elastos/elastos-runtime

Alle Issues in elastos/elastos-runtime

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.