Skąd wiadomo, że te zmiany są wasze?

Każda zmiana na tej stronie prowadzi do pull requesta w valeriansaliou/sonic, gdzie widać autora i datę scalenia.

Kto zdecydował o przyjęciu zmian w Sonic?

Opiekunowie projektu Sonic: przejrzeli zmianę i włączyli ją do swojego kodu. Na tej stronie są tylko zmiany przyjęte, bez otwartych i zamkniętych bez scalenia.

Gdzie jest pełny opis tej poprawki?

W Nowinkach technicznych: co nie działało, co zmieniliśmy, jak to sprawdziliśmy i jaki jest efekt, własnymi słowami.

Ile waszych zmian przyjęto w Sonic?

5 przyjętych zmian: pierwszą scalono 15 września 2026, ostatnią 5 października 2026.

W jakim języku napisany jest Sonic?

Rust. W tym języku są też nasze zmiany na tej stronie.

Jak wygląda wysłanie poprawki?

Otwieramy pull request z poprawką w valeriansaliou/sonic. Opiekunowie przeglądają zmianę, a gdy mają uwagi, poprawiamy ją, aż ją scalą.

Po co poprawiacie cudzy kod?

Na takich projektach stoją projekty naszych klientów. Błąd poprawiony u źródła znika u wszystkich, a my znamy od środka kod, na którym budujemy.

Gdzie są wszystkie wasze kontrybucje?

Na stronie Kontrybucje: 65 projektów i 125 przyjętych zmian, każdy projekt z osobną stroną.

Czy możecie poprawić błąd w Sonic albo w innej bibliotece, której używa mój projekt?

Tak. Zgłaszamy i poprawiamy go u źródła, a do czasu wydania poprawionej wersji zostawiamy w Twoim projekcie bezpieczne obejście.

Sonic: nasze zmiany w projekcie open source

Lekki silnik wyszukiwania w Ruście, alternatywa dla Elasticsearch, która działa w kilku megabajtach pamięci.

Wszystkie kontrybucje

Sonic

github.com/valeriansaliou/sonic

Język: Rust
Gwiazdki na GitHubie: 21 357
Strona projektu: crates.io/crates/sonic-server

5przyjętych zmian

Od 15.09.2026 do 5.10.2026.

9. miejsce wśród 64 projektów na GitHubie z naszymi zmianami, według gwiazdek. Pierwszy jest Zed (91 587).

Wszystkie zmiany przyjęte w Sonic

Od najnowszej, w brzmieniu z repozytorium projektu. Każdy wiersz otwiera pull request z datą scalenia.

Październik 2026

3

Wrzesień 2026

2

Co zmieniły te poprawki

Kopia zapasowa przez TRIGGER backup działa, gdy magazyn jest w użyciu, kopie obejmują znowu kubełki FST, kanał nie gubi miejsca dla klienta po błędzie odczytu, a dokumentacja opisuje limit nazw i bufor zapisu.

Wszystkie kontrybucje

Błąd, poprawka i wniosek

Skrót naszego opisu z Nowinek technicznych: co nie działało, co zmieniliśmy i co z tego wynika dla naszej pracy.

Co nie działało

Kopia zawodziła przy otwartym magazynie

Po zapisie komendą PUSH baza RocksDB zostaje otwarta w puli, a TRIGGER backup próbował otworzyć ją drugi raz i trafiał na zajęty plik LOCK. Na świeżym serwerze nie było jeszcze katalogów magazynów.

Co zmieniliśmy

Kopia z otwartej instancji

Gdy magazyn jest w puli, kopia powstaje z tej instancji po zrzuceniu buforów na dysk. Brakujący katalog jest pomijany zamiast błędu.

match pooled_store {

    Some(store) => kv_backup_engine.create_new_backup_flush(&store.database, true),

    None => {

        let origin_kv = self.open(store_id, |_| {})?;

        kv_backup_engine.create_new_backup(&origin_kv)

}

}

Czego nas to nauczyło

Kopia zapasowa robiona w trakcie pracy musi brać spójny stan, a nie blokować magazyn albo czytać go w połowie zapisu.

To ta sama zasada, którą stosujemy w kopiach danych klientów.

Rust: nasze projekty

Inne projekty z naszymi zmianami: Rust

6 projektów w tej technologii ma nasze przyjęte zmiany. Pasek to gwiazdki repozytorium, obok liczba naszych zmian. Każdy wiersz prowadzi do strony projektu.

Rust: nasze projekty i kod

Rust