P4 Stage 1: zunifikuj parsowanie błędów PBN przez ErrorRecord#611
Merged
Conversation
Atrybut wiążący model w getterach stron PBN niósł nazwę z monorepo (pbn_api). Ujednolicony z pakietem django-pbn-client: baza deklaruje class-attr `model_class = None`, konstruktor nie przesłania go None-em, a InstitutionGetter/ZrodlaGetter/PublisherGetter oraz shim ThreadedMongoDBSaver używają nowej nazwy. manage.py check: OK; pakiet + test_helpers: 40 passed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ges/
Krok 1 planu ekstrakcji: BPP konsumuje pbn-client i django-pbn-client jako
normalne zależności z PyPI (0.1.0, github.com/iplweb/*) zamiast lokalnych
memberów uv workspace.
- usunięto katalog packages/ (kopie robocze) — źródłem jest teraz PyPI,
- pyproject: usunięto [tool.uv.workspace] i wpisy `{ workspace = true }`
z [tool.uv.sources] (django-import-export git-source zostaje); deps
pbn-client/django-pbn-client bez zmian,
- pytest.ini: testpaths = src (bez packages),
- Dockerfile: usunięto 4× `COPY packages/` (obraz nie ma już tego katalogu),
- .dockerignore: usunięto regułę README paczek,
- uv.lock: przeliczony (paczki z indeksu, nie editable).
Weryfikacja: paczki zainstalowane z PyPI (==0.1.0, nie editable);
manage.py check OK; makemigrations --check bez dryfu w pbn_api/django_pbn_client
(pozostały dryf to pre-existing third-party AutoField: favicon/flexible_reports/
siteblog); test_helpers + test_validators 31 passed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- pbn-client / django-pbn-client: >=0.2,<0.3 (wave 0.2 z PyPI), uv.lock przeliczony, - przepisany docs/deweloper/pakiety-pbn.md: architektura PyPI zamiast workspace (usunięty opis packages/ + Docker copy + komend na nieistniejące ścieżki), - zaktualizowane docs/deweloper/index.md i newsfragment, - usunięte 48 nieaktualnych wpisów packages/* z .test_durations. Weryfikacja: manage.py check OK; makemigrations --check bez dryfu pbn; test_helpers + test_validators 31 passed na paczkach 0.2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pbn-client 0.2 przemianował parametr konstruktora publication_pk -> correlation_id (z property publication_pk do odczytu, ale nie jako kwarg konstruktora). Test kolejki konstruował wyjątek z publication_pk= -> TypeError. Adopcja nowej nazwy w teście. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…wnload - 6 modeli PBN (journal, institution, publisher, publication, scientist, conference) używa property `is_deleted` z BasePBNMongoDBModel zamiast magic-stringa `status == "DELETED"` (marker „[❌ USUNIĘTY]" bez zmian) - `check_mongoId` deleguje do `pbn_client.is_valid_object_id` (ta sama semantyka: 24-znakowy hex objectId) - `ensure_publication/person/institution_exists` delegują do `django_pbn_client.get_or_download` z zachowaniem wrappera `zapisz_mongodb` (fetch przed transakcją persystencji) - test blokujący zachowanie markera USUNIĘTY w __str__ 6 modeli Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dwa miejsca normalizowały dane osobowe autora z PBN własnymi, rozjeżdżającymi się łańcuchami preferencji: - pbn_api/models/publication.py (_normalizuj_autora): lastName + firstName/givenNames/name, brak familyName; - pbn_import/.../pbn_importuj_uid.py: familyName/lastName + givenNames/name, brak firstName, brak guardu na nie-dict. Oba delegują teraz do jednego źródła prawdy — pbn_client.normalize_author_name (unia kluczy: familyName→lastName, firstName→givenNames→name; nie-dict → brak danych). Paczka używa None jako sentinela pustki; oba site'y koerują go do "" (szablon rekordu i str(autorzy) w logach zakładają puste stringi, a display-line importu składa f-string). Zysk: rozpoznanie familyName (publication) i firstName (import) tam, gdzie wcześniej wypadało puste; bezpieczeństwo na nie-dict w komendzie importu. Zachowany zamrożony ""-kontrakt (test goły-UID) + nowy test familyName. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Interaktywne narzędzie diagnostyczne trzymało własne kopie logiki, którą mamy teraz w pbn-client. Podmienione na jedno źródło prawdy: - _extract_object_id → pbn_client.decode_publication_object_id (mapowanie endpoint_choice → bez_oswiadczen: "publications"=all-in-one → False, "repositorium" → True). Paczka przy niejednoznacznej odpowiedzi (lista != 1 element, zły typ) RZUCA zamiast po cichu zwracać None — narzędzie łapie to głośno, pokazuje surową odpowiedź i pyta usera czy wyjść czy jechać dalej z objectId=None (decyzja usera: rzadko używane, niech krzyczy i pyta). - lokalny _key → pakietowe statement_key_pbn / statement_key_intended; różnice liczy diff_statements, część wspólną (której paczka nie zwraca) liczymy lokalnie na tych samych kluczach. Testy: nowy test integracyjny (niejednoznaczna odpowiedź → głośny błąd + przerwanie pod --yes-all) + unit gałęzi "kontynuuj" (zwraca None). 16 passed w suicie komendy, 339 w całym pbn_api. ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…w paczce) Rozpoznanie 422 "was not exists!" robi teraz RAZ endpoint paczki (pbn_client.get_publication_by_id rzuca PublicationNotFound) — BPP nie duplikuje już tej detekcji w call-site. - pbn_api/exceptions.py: BrakIDPracyPoStroniePBN staje się aliasem PublicationNotFound (przypisanie, ta sama klasa, `is`) zamiast osobnej podklasy HttpException. Dzięki temu istniejące `except BrakIDPracyPoStroniePBN` (odswiez_tabele_publikacji kasujący cache; worker importu zwracający per-item fail) łapią wyjątek rzucany przez paczkę. To CO INNEGO niż BPPPublicationNotFound (brak rekordu BPP). - pbn_integrator/utils/publications.py (_pobierz_pojedyncza_prace): usunięto ręczną re-detekcję markera w treści; PublicationNotFound propagujemy, zwykły HttpException (w tym 404) leci dalej, 500 "Internal server error" nadal → None. Decyzja 404 (zapisana w planie): 404 bywa przejściowy → NIE jest "brak pracy", nie kasuje lokalnego cache'u. Ani paczka, ani BPP nie mapują 404 na PublicationNotFound. Testy przepisane na nowy kontrakt: alias-identity, PublicationNotFound z paczki → propagacja jako BrakID (pola HTTP zachowane), 404 ≠ BrakID, goły 422 nie jest już re-detektowany przez BPP, 500 → None. 540 passed (pbn_integrator + pbn_api), ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…_to_model) pobierz_mongodb dostaje parametr on_error sterujący zachowaniem przy błędzie zapisu POJEDYNCZEGO rekordu do lokalnego lustra BPP (IntegrityError, zły kształt danych itp. — po naszej stronie, nie PBN): - "raise" (default) — fail-fast jak dotąd: pierwszy błąd propaguje i przerywa batch (download_pbn_objects, goła pętla save bez try/except). Zwraca None. - "skip" — deleguje do pakietowego download_to_model: zły rekord logowany (pełny traceback) + liczony, import reszty kończy się. Zwraca DownloadResult(processed, errored). Dla masowych synchronizacji (tysiące rekordów), gdzie jeden zepsuty rekord nie powinien wywalać całego przebiegu. Zachowanie domyślne bez zmian — żaden istniejący caller nie zmienia zachowania (default "raise"). Adopcja download_to_model włączana opt-in per-getter po decyzji. Nieznana wartość on_error → ValueError (głośno). Etykieta progress-baru ujednolicona między trybami (fasada nie forwarduje pbar_label). Testy: fail-fast default, skip kontynuuje+liczy, ValueError. 3 nowe + 12 istniejących mongodb_ops passed, check OK, ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Trzy pliki w pbn_api były czystymi re-eksportami z pakietów PBN (`from pbn_client.X import *`) — zbędna warstwa pośrednia po tym jak kod klienta wyszedł na PyPI. Usunięte + repoint callerów wprost na paczkę: - pbn_api/const.py → callery: from pbn_client.const import ... (22 plików) - pbn_api/utils.py → from pbn_client.dict_utils import ... (2) - pbn_api/client/transport.py → from pbn_client.transport import ... (1) Spójne z resztą kodu po ekstrakcji (mongodb_ops itd. już importują wprost z pbn_client/django_pbn_client). ZOSTAWIONE świadomie: - pbn_api/exceptions.py — hybryda: wyjątki BPP-specific + alias BrakIDPracyPoStroniePBN = PublicationNotFound. - pbn_api/models/base.py — seam pod przyszłą Fazę 3 (abstrakcyjne modele). Czysto mechaniczne (tylko podmiana ścieżki modułu, nazwy bez zmian). Review: fable PASS + codex SHIP (brak defektów). manage.py check OK, pbn_api 339 passed, zero nowych naruszeń ruff. Pre-existing lint (F401/I001/UP012 w tkniętych plikach) świadomie NIE ruszany — poza zakresem. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cztery rozproszone, kruche parsery błędów wysyłki do PBN (format_pbn_error,
parse_pbn_api_error, parse_error_details, admin exception_details) stają się
cienkimi adapterami nad jednym, wspólnym kontraktem ErrorRecord.
Rdzeń (ErrorRecord + totalne parse() + serialize() do formatu v1) mieszka w
pakiecie pbn-client (0.2.1) jako czysta, framework-niezależna wiedza o
protokole PBN. W BPP zostają wyłącznie Django-owe adaptery display. Do czasu
publikacji pbn-client 0.2.1 na PyPI, zależność jest pinowana git-source w
[tool.uv.sources] (do usunięcia po release).
Rollout reader-first (Stage 1): readery rozumieją legacy ORAZ format v1;
writery bez zmian. serialize() istnieje, ale nie jest podpięty (Stage 2).
Byte-identyczność realistycznego legacy pinowana golden testami
charakteryzacyjnymi (zdjętymi sprzed unifikacji). Świadome ulepszenia:
format_pbn_error nie rzuca już TypeError na payloadzie-liczbie; admin
exception_details porzuca hack split('"details":')[1][:-3].
Naprawy z 2× adwersaryjnej recenzji Fable: (1) readery poprawnie obsługują
blob v1 (pole `wire`; guard >512 tylko dla legacy) — bez tego Stage 1 nie
kupował ochrony przed deploy-race; (2) parse() jest totalne także na
RecursionError/OverflowError/MemoryError z wrogiego body; (3) content_json_valid
odróżnia JSON null od niepoprawnego body; (4) serialize() capuje wszystkie pola
(blob dowodliwie < 65535). Szczegóły: docs/deweloper/p4-error-record-unifikacja-spec.md §9.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…612) download_disciplines/sync_disciplines przestają trzymać otwartą transakcję przez czas remote-calla do PBN. Pobranie idzie teraz przez sync_dictionary(fetch, upsert) (wzorzec materialize-before-atomic z django-pbn-client 0.2.1): fetch poza transakcją, upsert atomowo. Matching do modeli BPP (Dyscyplina_Naukowa/TlumaczDyscyplin) wydzielony do osobnej @transaction.atomic metody — zostaje w BPP (BPP-specific). Usunięto martwy `if discipline.name == "weterynaria": pass`. Test-strażnik (transaction=True) dowodzi, że fetch dzieje się poza transakcją. Zależność django-pbn-client 0.2.1 pinowana git-source (do usunięcia po publikacji na PyPI). Stack: na feat/pbn-p4-reader. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Conflicts: # pyproject.toml # src/pbn_api/client/disciplines.py # src/pbn_api/tests/test_client_disciplines.py # src/pbn_export_queue/templatetags/pbn_queue_extras.py # src/pbn_export_queue/views/utils.py # uv.lock
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cel
Cztery rozproszone, kruche parsery błędów wysyłki do PBN (
format_pbn_error,parse_pbn_api_error,parse_error_details, adminexception_details) →cienkie adaptery nad jednym kontraktem
ErrorRecord.Rdzeń (
ErrorRecord+parse+serialize) mieszka w pakiecie pbn-client(0.2.1) jako czysta wiedza o protokole — patrz iplweb/pbn-client#7. W BPP
zostają tylko Django-owe adaptery display.
Rollout reader-first (Stage 1)
Readery rozumieją legacy ORAZ format v1; writery bez zmian.
serialize()istnieje, ale nie jest podpięty (Stage 2 — dopiero po wdrożeniuStage 1 na całej flocie). To eliminuje deploy-race przy przełączaniu writerów.
Byte-identyczność
Golden testy charakteryzacyjne (
test_error_record_golden.py+ fixturedata/error_record_golden.json) zdjęte z outputu sprzed unifikacji pinująbyte-identyczność realistycznego legacy (per-funkcja, na jej realnej domenie
wejścia). Świadome ulepszenia: koniec crasha
TypeErrorna payloadzie-liczbie;koniec hacka
split('"details":')[1][:-3]w adminie.Recenzje adwersaryjne (2× Fable) — naprawione
wirereadery klasyfikowały blob v1 jako„nie-PBN" / renderowały surowy JSON → Stage 1 nie kupował ochrony. Naprawione
test_error_record_v1_reader.py.parse():RecursionError/OverflowError/MemoryError.null↔ niepoprawny body: polecontent_json_valid.Rozliczenie findingów:
docs/deweloper/p4-error-record-unifikacja-spec.md§9.Zależność / merge order
[tool.uv.sources]pinujepbn-clientgit-source do commita gałęzifeat/error-record(pakiet PUBLIC, CI go pobierze). Po wydaniu pbn-client0.2.1 na PyPI usunąć wpis z
[tool.uv.sources]— pin>=0.2.1,<0.3wystarczy. Merge dopiero po iplweb/pbn-client#7.
Testy
Pełne
pbn_export_queue+pbn_api: 601 passed (w tym playwright adminchangelist renderujący
exception_details). ruff +manage.py checkczyste.Stack: na
feat/pbn-shims(#609).🤖 Generated with Claude Code