Două reguli și o legătură moartă între ele

Am parcurs situl de producție cum se cuvine, întâia oară după multă vreme: fiecare legătură internă urmată, fiecare alternativă de limbă declarată verificată, fiecare bloc de date structurate validat, fiecare imagine verificată pentru text alternativ.

1776 de pagini, 1750 de intrări în harta sitului și exact un defect. Zero orfani, zero lanțuri de redirecționare, zero erori de alternativă de limbă peste 17218 declarații, zero blocuri de date structurate nevalide peste 1642, zero imagini fără text alternativ peste 15463 și 920 de imagini de previzualizare socială care răspund toate 200.

Singurul defect erau 18 adrese care întorceau 404: paginile de documentație ale două panouri de facturare, în toate cele nouă limbi. Fiecare dintre acele 18 avea exact o legătură internă care arăta spre ea, de pe pagina de integrare a aceluiași produs în aceeași limbă.

Amândouă jumătățile de acolo sunt dinadins. Tocmai asta le face să merite consemnate.

Cele două reguli

Unele dintre integrările noastre stau în spatele unui comutator de lansare. Când comutatorul este oprit, furnizorul dispare din catalog, din harta sitului, din numărători și din selectorul de tip din panou, toate derivate dintr-un singur tabel, așa că nu există o a doua listă de uitat.

Două dintre ele nu sunt tocmai obișnuite. Pentru FOSSBilling și Paymenter există un modul pe care îl instalați în panoul lor, iar pagina de la /integrations/fossbilling descrie modulul acela. Nu este o pagină despre o conexiune pe care o oferim; este o pagină despre un lucru pe care îl puteți descărca astăzi. Așa că există o regulă care ține în picioare paginile acelea două de integrare atunci când furnizorul din spatele comutatorului este ascuns, iar ea își poartă motivul în sursă.

Pagina de documentație este cazul opus. /docs/fossbilling descrie conexiunea, care este exact ce oprește comutatorul, deci ea dispare odată cu furnizorul.

Amândouă regulile sunt corecte. Un slug, două suprafețe, două răspunsuri, iar codul are două funcții în loc de una care ar fi greșită jumătate din timp.

Ce nu verificase nimeni este ce se întâmplă între ele. Pagina care supraviețuia purta legătura tematică spre cea dispărută.

Regula era deja consemnată

Funcția care produce legătura aceea rezolvă o cale de documentație pentru un slug de integrare. Propriul ei comentariu spunea, dinainte de toate acestea, că o legătură spre un ghid care nu există nu este o legătură tematică, ci una moartă.

Regula era acolo. Era măsurată față de lista greșită: mulțimea paginilor de documentație care există în sursă, în loc de mulțimea celor care răspund în compilarea aceasta. Cele două sunt aceeași mulțime aproape tot timpul, iar ziua în care se deosebesc este ziua în care ceva este ascuns.

Reparația este o singură linie. Nu asta este partea interesantă; partea interesantă este că o regulă corectă, scrisă pe larg în locul căruia îi aparține, nu este un control. Proza dintr-un comentariu descrie o intenție. Numai ceva care rulează vă poate ține de ea.

Un al treilea caz pe care nicio parcurgere nu l-ar fi putut găsi

Am scris o gardă în loc să reparăm doar linia: pentru fiecare slug de integrare, calea de documentație rezolvată trebuie să fie una pe care compilarea aceasta o servește cu adevărat. A fost dovedită roșie mai întâi și a raportat cele două pagini pe care le găsise parcurgerea.

A raportat și o a treia: integrarea noastră de server de copii de rezervă, care se află în spatele altui comutator. Pagina ei de documentație este ascunsă, iar legătura spre ea era construită exact la fel.

Motivul pentru care niciun parcurgător nu o va găsi vreodată pe aceea este că și pagina ei de integrare este ascunsă. Legătura moartă trăia pe o pagină care întoarce ea însăși 404, deci nu există nicio cale din afară spre lucrul care este greșit. Ar fi ieșit la iveală în ziua în care cineva ar fi pornit comutatorul acela și ar fi livrat o pagină cu o legătură ruptă pe ea, iar cele două întâmplări ar fi fost la săptămâni distanță.

Un parcurgător poate găsi defecte numai pe paginile la care se poate ajunge. Asta sună evident scris pe hârtie și este ușor de uitat când o parcurgere se întoarce curată, fiindcă o parcurgere curată pare o afirmație despre cod în loc de una despre paginile care s-au nimerit să fie vizibile.

Garda mai are un test care nu face nimic altceva decât să îl țină cinstit pe primul: afirmă că mai mult de zece sluguri chiar se rezolvă spre o pagină de documentație. Fără el, o schimbare care ar face rezolvatorul să nu întoarcă nimic pentru niciun slug nu ar produce nicio legătură moartă și nicio legătură tematică, iar cele două se citesc la fel într-o rulare de teste verde.

Cealaltă jumătate: a-i spune unui motor de căutare că ceva s-a schimbat

Aceeași rundă a adăugat un canal de anunțare, care este un lucru mărunt cu o singură surpriză în el.

Protocolul este un singur POST care spune mai multor motoare de căutare că o adresă s-a schimbat. Stăpânirea gazdei se dovedește servind o cheie ca fișier text la rădăcină. Cheia noastră vine din mediu, iar când lipsește, tot lucrul nu face nimic și o spune o dată. Aceea este starea obișnuită în dezvoltare și în fiecare test.

Două amănunte merită repetate, fiindcă amândouă sunt capcane.

Fișierul de cheie este servit printr-o rescriere, fiindcă o rută dinamică nu poate sta la rădăcină lângă segmentul de limbă. O rescriere care s-ar potrivi cu orice punct txt la rădăcină ar înghiți și fișierul robots. Două lucruri o opresc: rescrierea rulează în faza care vede numai cererile cu care nu s-a potrivit niciun fișier adevărat, iar tiparul cheii cere cel puțin opt caractere, în timp ce robots are șase, iar llms patru. Limita de jos nu este curățenie, ci a doua încuietoare.

Iar anunțarea atârnă de funcția care știe deja că s-a schimbat conținut public, nu de livrare. O versiune care atinge doar un ecran din panou ar vesti altfel de fiecare dată 1750 de adrese ca modificate, ceea ce este un fel bun de a fi ignorat. Când se schimbă tabelul de prețuri, cele două rute care redau prețuri sunt anunțate în nouă limbi, adică 18 adrese.

Lucrul care arăta a configurare greșită

Prima anunțare adevărată după livrare, cu cheia de producție la locul ei, a întors 403.

Fișierul de cheie întorcea 200 de oriunde am încercat, inclusiv cu un agent de utilizator de parcurgător. Fiecare ingredient se verifica. Pasul următor firesc este să vă duceți să vă uitați la configurația de margine, sau la rescriere, sau la ordinea fazelor, și acolo se duce o oră.

Ce am făcut în schimb a fost să încercăm două lucruri mai mărunte. O anunțare a unei singure adrese a întors 200 numaidecât. Aceeași anunțare în masă, un minut mai târziu, a întors tot 200, la amândouă punctele de intrare.

Așadar 403-ul era un efect de primă atingere de partea lor, nu un defect de partea noastră. Fișierul de cheie nu fusese încă preluat și pus în cache de serviciul primitor în clipa în care a sosit prima cerere în masă.

Am consemnat asta acolo unde trăiește manualul de operare, fiindcă eșecul este croit desăvârșit ca să trimită pe cineva la vânătoare: codul de stare spune interzis, care este o afirmație despre permisiune, iar totul despre permisiune era corect. Înainte să cercetați un eșec de autorizare la o primă cerere, faceți aceeași cerere din nou. Nu costă nimic și este cea mai ieftină ipoteză din listă.

Există o notă înrudită pentru cine rotește cheia aceea: fișierul este servit cu o oră de cache, deci o rotire cere o golire sau o oră de răbdare, iar în fereastra aceea același 403 înseamnă cu totul altceva.

Ce am consemna

1. 01Două reguli corecte pot produce un defect în cusătura dintre ele. Niciunul dintre stăpâni nu greșește și niciunul nu se uită.
2. 02Același identificator poate avea două suprafețe cu două răspunsuri corecte. Două funcții, nu una.
3. 03O regulă dintr-un comentariu nu este un control. A noastră era scrisă pe larg și măsurată față de lista greșită.
4. 04Ce există și ce răspunde sunt mulțimi deosebite, iar ele se despart exact atunci când ceva este ascuns.
5. 05Un parcurgător găsește defecte numai pe paginile la care se poate ajunge. Al nostru nu putea vedea deloc al treilea caz.
6. 06O gardă găsește exemplarul care încă nu a fost livrat. Acesta este întregul motiv pentru care scrieți una în loc să reparați linia.
7. 07Dați fiecărei gărzi un test care dovedește că se uită. Nicio legătură moartă și nicio legătură deloc se citesc la fel.
8. 08O limită de jos într-un tipar poate fi o graniță de securitate. Opt caractere sunt ce ține o rescriere departe de fișierul robots.
9. 09Anunțați schimbările de conținut din lucrul care știe că s-a schimbat conținut, niciodată din livrare.
10. 10Reîncercați înainte să diagnosticați un eșec la prima cerere. Un interzis care devine o izbândă un minut mai târziu nu a fost niciodată despre permisiune.

Ca să fie limpede ce este aceasta: parcurgerea a acoperit 1776 de pagini față de producție și 1750 de intrări în harta sitului, cu 913 date de modificare dintre care niciuna nu era în viitor, reparația este o singură linie păzită de trei teste dovedite roșii mai întâi, calea de anunțare a fost exersată cap la cap față de un punct de intrare simulat, inclusiv cinci căi de eșec, iar baleiajul peste o compilare de producție de sine stătătoare s-a încheiat la 96 verde. Nedovedit: la vremea când a fost scrisă reparația, ea era verde pe o compilare de producție locală și nu fusese încă adeverită în producție, iar două familii de rute din parcurgere nu au produs nicio pagină, fiindcă registrele lor sunt goale.

Din munca de platformă la Provibr. Ce poate și ce nu poate duce cu ea o migrare de facturare se află în cincisprezece lucruri care nu pleacă, o livrare al cărei pas de schemă nu a rulat niciodată se află în migrarea care nu a rulat niciodată, iar o altă verificare care era verde fiindcă nu ajungea niciodată acolo se află în verde fiindcă nu putea ajunge acolo.