Перевірка, яка завжди істинна
У цій службі 23 інструкції UPDATE. Рівно одна з них дивиться, чи змінила вона щось. Ця перевірка така:
'success' => $n->rowCount() >= 0
rowCount() повертає 0, коли жоден рядок не підійшов. Нуль більший або дорівнює нулю. Перевірка проходить, хай там що.
Для чого ця інструкція
Вона зберігає позначку: чи хоче власник лічильника тижневий підсумок поштою. Адреса лежить в окремій таблиці, і рядок з'являється там лише після того, як хтось натиснув посилання підтвердження в листі, про який сам попросив. Такий рядок мають чотири лічильники. Діючих — 2 218.
Отже, для 99,8 % лічильників UPDATE не влучає нікуди. Кінцева точка відповідає success: true, а налаштування не зберігається, бо зберігати його ніде.
Коментар над нею слушний
Трьома рядками вище, у тій самій функції:
«Тільки там, де є підтверджений зворотний шлях. Без нього немає адреси, куди міг би піти лист, — і позначка пообіцяла б те, чого не стається.»
Це рівно так. Хтось подумав про цей випадок, зрозумів його і записав міркування. А тоді рядок нижче вжив >= там, де міркування вимагало >.
На це варто подивитися прямо, бо звичне пояснення — ніхто не подумав — лежить під рукою і воно хибне. Думка є у файлі. Підвів один знак, у місці, де хибна й правильна версія виглядають із першого погляду однаково і поводяться однаково в кожній перевірці, що має рядок для оновлення.
Нікого не обманюють
Ось частина, яку легко було б оминути, і чиє оминання зробило б цей допис драматичнішим і менш правдивим.
Сторінка взагалі не малює цієї позначки, якщо рядка немає. Екраном далі, у коді, що складає блок власника, ту саму таблицю питають першою, і весь блок пропускається, коли запит вертається порожнім. Власник без підтвердженої адреси ніколи не бачить цього перемикача, ніколи його не натискає і ніколи не дістає хибного підтвердження.
Зламана перевірка досяжна лише прямим зверненням до кінцевої точки з чинним токеном. Той, хто це зробить, дістане success: true і жодного збереженого налаштування. Це справжня вада, і вузька.
Чому це все ж варто записати
Можливість безпечна завдяки сторожу, якого ніхто не записав як сторожа. Рядок, що існує заради безпеки, її не забезпечує. Забезпечує умова малювання в іншій функції, чий коментар пояснює, чому позначку сховано, — але не те, що від її схованості щось залежить.
Приберіть або перебудуйте цю умову — розумна річ при переробці панелі налаштувань — і вада стає видимою миттєво, а ніщо ніде не пов'язує ці дві правки. Безпека справжня, вона випадкова, а випадкова безпека — та, що зникає під час сторонньої праці.
Той самий код робить це правильно на файл далі. Відповідна функція вебрингу питає, чи є рядок, повертає хибу, якщо немає, і зовсім не надсилає оновлення. У тій таблиці зараз нуль рядків, отже, функція повертає хибу при кожному виклику — і це правильна відповідь.
Загальна форма
UPDATE, що не влучив у жоден рядок, у жодній базі не помилка. Це успішна інструкція, яка нічого не зробила, і кожен шар вище звітує про успіх, доки ніхто не спитає. Двадцять дві тутешні інструкції не питають, і для більшості це гаразд: вони оновлюють рядок, існування якого запит уже довів.
Єдина, якій треба було спитати, спитала так, що провалитися неможливо. rowCount() >= 0 — це не слабка перевірка, це відсутність перевірки в костюмі перевірки — і це гірше, ніж жодної, бо наступний, хто прочитає функцію, побачить оглянутий результат і перестане дивитися.
Вислів rowCount() > 0 трапляється в цьому коді нуль разів. Саме це число робить із друкарської помилки щось варте допису: не те, що один раз написали не так, а те, що ніде не було правильного випадку, з яким це можна було б звірити.
Виправлено 28 серпня 2026 року. Кінцева точка тепер питає, чи є рядок, перш ніж писати — так, як функція вебрингу на файл далі робила завжди, — і інакше відповідає хибою. Очевидне виправлення в один знак, перевіряти натомість «більше за нуль», спершу виміряли й відкинули: драйвер повідомляє число змінених рядків, а не знайдених. Той, хто ставить позначку в значення, яке вона вже має, нічого не змінює — і та версія повідомила б про невдачу для дії, з якою все було гаразд. Обидві версії хибні, лише в протилежні боки.