De controle die altijd waar is

Er staan 23 UPDATE-opdrachten in deze dienst. Precies één ervan kijkt na of er iets veranderd is. Die controle is:

'success' => $n->rowCount() >= 0

rowCount() geeft 0 terug wanneer geen enkele regel paste. Nul is groter dan of gelijk aan nul. De controle komt er hoe dan ook door.

Waar de opdracht voor is

Ze bewaart een vinkje: of de eigenaar van een teller een weekoverzicht per e-mail wil. Het adres staat in een aparte tabel, en daar verschijnt pas een regel nadat iemand op de bevestigingslink heeft geklikt in een bericht waar hij om vroeg. Vier tellers hebben zo'n regel. Er zijn er 2.218 actief.

Bij 99,8% van de tellers past de UPDATE dus op niets. Het eindpunt antwoordt success: true en de instelling wordt niet bewaard, want er is niets om haar in te bewaren.

Het commentaar erboven klopt

Drie regels hoger, in dezelfde functie:

"Alleen waar een bevestigde retourweg bestaat. Zonder die weg is er geen adres waar de brief naartoe zou kunnen — en het vinkje zou iets beloofd hebben dat niet gebeurt."

Dat klopt precies. Iemand heeft over dit geval nagedacht, het begrepen en de redenering opgeschreven. Daarna gebruikte de regel eronder >= waar de redenering om > vroeg.

Dit verdient het om er recht in de ogen te kijken, want de gebruikelijke verklaring — niemand heeft eraan gedacht — ligt voor de hand en is fout. Het denken staat in het bestand. Wat faalde, is één teken, op een plaats waar de foute en de goede versie er op het eerste gezicht hetzelfde uitzien en zich in elke test met een regel om bij te werken hetzelfde gedragen.

Er wordt niemand voorgelogen

Hier komt het deel dat makkelijk weg te laten zou zijn, en dat weglaten zou dit bericht dramatischer en minder waar maken.

De pagina tekent dat vinkje niet tenzij de regel bestaat. Eén scherm verderop, in de code die het instellingenvak van de eigenaar tekent, wordt dezelfde tabel eerst bevraagd, en het hele blok wordt overgeslagen wanneer de bevraging leeg terugkomt. Een tellereigenaar zonder bevestigd adres ziet de knop dus nooit, klikt er nooit op, en krijgt de valse bevestiging nooit.

De kapotte controle is alleen bereikbaar door het eindpunt rechtstreeks met een geldig token aan te roepen. Wie dat doet, krijgt success: true en geen bewaarde instelling. Dat is een echt gebrek en een smal gebrek.

Waarom het toch het opschrijven waard is

De voorziening is veilig door een bescherming die niemand als de bescherming heeft opgeschreven. De regel die bestaat om haar veilig te maken, maakt haar niet veilig. Wat dat wel doet, is een tekenvoorwaarde in een andere functie, waarvan het commentaar uitlegt waarom het vinkje verborgen is — niet dat er iets afhangt van het verborgen blijven.

Haal die tekenvoorwaarde weg of herstructureer haar — een redelijk ding om te doen bij het herontwerpen van een instellingenpaneel — en het gebrek wordt op slag zichtbaar, terwijl er nergens iets is dat de twee wijzigingen met elkaar verbindt. De veiligheid is echt, en ze is toevallig, en toevallige veiligheid is de soort die tijdens ongerelateerd werk verdwijnt.

Dezelfde code doet het één bestand verderop wel goed. De overeenkomstige functie van de webring vraagt of de regel bestaat, geeft false terug wanneer dat niet zo is, en geeft de update helemaal niet uit. Die tabel heeft op dit moment nul regels, dus die functie geeft elke keer dat ze aangeroepen wordt false terug, en dat is het juiste antwoord.

De algemene vorm

Een UPDATE die op geen enkele regel past, is in geen enkele database een fout. Het is een geslaagde opdracht die niets deed, en elke laag erboven meldt succes tenzij er iets vraagt. Tweeëntwintig van de opdrachten hier vragen niet, en voor de meeste is dat prima: ze werken een regel bij waarvan de aanvraag al bewezen had dat hij bestaat.

De ene die had moeten vragen, vroeg op een manier die niet kan zakken. rowCount() >= 0 is geen zwakke controle, het is de afwezigheid van een controle in het kostuum van een controle — en het is erger dan geen controle, want wie de functie daarna leest, ziet dat er een uitkomst wordt bekeken en kijkt niet verder.

De uitdrukking rowCount() > 0 komt in deze code nul keer voor. Dat is het getal dat van een tikfout van één teken iets maakte dat een bericht waard is: niet dat het één keer fout geschreven is, maar dat er nergens een goed exemplaar was om het mee te vergelijken.

Hersteld op 28 augustus 2026. Het eindpunt vraagt nu of de regel bestaat voordat het bijwerkt, zoals de webringfunctie één bestand verderop al deed, en antwoordt false wanneer dat niet zo is. De voor de hand liggende oplossing van één teken — in plaats daarvan tegen groter dan nul vergelijken — is eerst gemeten en afgewezen: het stuurprogramma meldt gewijzigde regels en geen passende regels, dus het vinkje op de waarde zetten die het al heeft verandert niets, en die versie zou mislukking gemeld hebben voor een handeling die in orde was. Beide versies zijn fout, in tegengestelde richting.