"Delegator had no such ruleset" — historia pewnego błędu w WISE
TLDR: Delegatorzy powinni zaaktualizować wise do wersji 0.19.5.
Nic tak nie denerwuje jak błąd, który uniemożliwia korzystanie z ulubionego programu. Szczególnie, jeżeli nic z nim nie możemy zrobić. Zwykle błędy są trywialne i udaje się je rozwiązać w ciągu kilku godzin. W przypadku tego błędu było jednak inaczej.
"Delegator had no such ruleset", opisany w https://github.com/noisy-witness/steem-wise-cli/issues/9 od początku stwarzał nam kłopoty. Problem występował niestale. Można by rzec — z rzadka. Pojawiał się raz na kilkadziesiąd voteorderów. Został zgłoszony przez @noisy 29 czerwca. Nie wydawał się wtedy dużym kłopotem, jako że nie występował często.
Niestety — w pierwszych dniach sierpnia sprawy nabrały rozpędu. Po dosyć dużej zmianie w kodzie przetwarzającym transakcje z blockchainu, która była konieczna do zaimplementowania reguły weight_for_period, błąd zaczął się pojawiać w praktycznie każdym przypadku. Zaczęliśmy intensywną diagnostykę. Napisałem specjalne automatyczne testy, które miały weryfikować błąd, próbowaliśmy odtworzyć sytuacje, które występowały na koncie @noisy. Cała sytuacja była o tyle ciekawa, że ani razu nie udało mi się odwtorzyć tych błędów na moim komputerze. Natomiast błąd na koncie @noisy szalał. Zaczęło dochodzić do sytuacji, w której użytkownicy byli walidowani według cudzych reguł.
Muszę przyznać, że kolejne dni przepełnione były frustracją. Postanowiliśmy stworzyć specjalny system raportowania wydarzeń (zdalne udostępnianie logów). Uruchomienie tego systemu diagnostycznego przyniosło zupełnie niespodziewany rezultat. Na serwerze Krzysztofa błędy przestały się pojawiać, synchronizacja przebiegała gładko. Jak to mówią programiści: działa! — dziwne.
W tym momencie skończyły nam się pomysły. Z braku lepszego zajęcia zacząłem przeglądać historię zmian w kodzie biblioteki. Wtedy natrafiłem na tę poprawkę:
https://github.com/noisy-witness/steem-wise-core/commit/0f32bb72c53de75053cdb004c4074b5b587fcf7f#diff-f0e55e336caf39ba655940f5ace4148eR149
którą sam napisałem parę dni wcześniej. Po zastanowieniu, doszedłem do wniosku, że kod, który w niej został poprawiony, wygląda na taki, który mógł spowodować wybór błędnego zestawu reguł do walidacji.
W tym momencie uruchomiłem tzw. test regresyjny. Tzn. usunąłem tę poprawkę i skompilowałem program na serwerze. Po uruchomieniu okazało się, że błąd znowu występuje. To potwierdziło nam, że problem od początku leżał w tym miejscu. Zatem został rozwiązany już kilka dni wcześniej, a my nie zdawaliśmy sobie z tego sprawy! Przez "cichą naprawę" u mnie — w zaaktualizowanej wersji daemona błędu nie było, natomiast u Krzysztofa — w starszej wersji, błąd hulał w najlepsze.
Morał z tej historii jest taki: nigdy nie naprawiać błędów bez uprzedniego napisania testów. Gdybym nie naprawił tego błędu "po cichu" — dużo szybciej zorientowalibyśmy się gdzie leży problem.
W związku z tym na przyszłość planujemy wprowadzić dokładniejsze testy jednostkowe, a przede wszystkim stworzyć środowisko testów scenariuszowych, tj. stworzyć takiego naszego "udawanego" użytkownika, który będzie korzystał z wise wg ustalonego scenariusza — i raportował nam wszelkie błędy i problemy :)
Jak widzicie, rozwiązanie tego problemu nie było łatwe. Wszystkich, którzy nie mogli z jego powodu korzystać z Wise serdecznie przepraszam.
Zapraszam do zaaktualizowania WISE do wersji 0.19.5 :)
$ npm install -g steem-wise-cli
Warto jakbyś jeszcze zrobił jakieś ELI5 na czym polegał błąd, bo dla dużej części osób to ciągle może być czarna magia :)
Cóż. Sam błąd był prosty. Trudne było jego znalezienie. Niełatwo wyjaśnić działanie błędu bez wyjaśniania wewnętrznego mechanizmu działania wise ;) W skrócie: w momencie zmiany przetwarzania z operacji na transakcje — wyrażenie warunkowe if w miejscu odpowiedzialnym za wybór rulesetu do walidacji voteorderu powinno zostać zmienione, aby przystawało, ale nie zostało zmienione do końca, co spowodowało powstanie błędnego zlepka kodu, który zawsze zwracał prawdę. Ale nie to jest tutaj nauczką dla nas. Kod WISE jest pisany razem z ogromną ilością testów jednostkowych (ok 400). Staram się, aby cały kod był nimi pokryty. W tym miejscu jednak była luka. Nauczki są dwie: 1) dokładniejesze testy jednostkowe, 2) testy scenariuszowe. Im więcej testów, tym mniej potencjalnych błędów. Działają jak sito. Teraz trzeba tylko zmniejszyć oczka ;)
Wyciągnięty wniosek powinien być inny raczej: na nic zdają się testy jednostkowe bez testów integracyjnych :P
Czyli już można kurować? :P
Można! :)
Po raz kolejny STEEM został uratowany.
Dziękuję Jędrzeju.
Zapomniałem jeszcze podziękować @nicniezgrublem i @noisy za ich dużą pomoc przy rozwiązywaniu tego problemu! :)
Congratulations @jblew! You have completed the following achievement on Steemit and have been rewarded with new badge(s) :
Click on the badge to view your Board of Honor.
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Congratulations @jblew! You have received a personal award!
Click on the badge to view your Board of Honor.
Congratulations @jblew! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
Click on the badge to view your Board of Honor.
If you no longer want to receive notifications, reply to this comment with the word
STOPDo not miss the last post from @steemitboard:
Congratulations @jblew! You received a personal award!
Click here to view your Board of Honor
Do not miss the last post from @steemitboard:
Congratulations @jblew! You received a personal award!
You can view your badges on your Steem Board and compare to others on the Steem Ranking
Vote for @Steemitboard as a witness to get one more award and increased upvotes!