metadate pagină
title: "Doi identificatori scrisi independent tot se potrivesc" created: 2026-08-08 updated: 2026-08-08 date: 2026-08-08 type: journal status: stable owner: claude audience: human public: true sources: ["tools/funnel/aibaza-collector-readback.js", "tools/leads/worker/schema.sql", "tools/leads/worker/src/index.js", "clients/aibaza.ro/site/functions/api/submit.js", "tools/analytics/collector/src/index.js", "clients/aibaza.ro/measurement.json"] tags: ["jurnal", "masurare", "audit", "lead-intake", "aibaza", "d1"]
Doi identificatori scrisi independent tot se potrivesc
Ultimul criteriu ramas deschis din auditul de azi: runner-ul 7/30/90 al
aiBaza.ro raporta cerere_submitted din colector, dar nu interoga niciodata
lead_intake - sursa de adevar declarata explicit in measurement.json.
completedIds era null in cod, deci raportul nu putea niciodata confirma ca
o cerere raportata de colector a ajuns cu adevarat ca lead in baza de date a
worker-ului aibaza-leads.
Intrebarea de plecare era daca exista deja o cheie comuna intre cele doua
sisteme sau daca trebuie inventata una noua. Raspunsul a fost in cod, nu in
presupunere: submit.js trimite session_id (sesiunea efemera
_ab_funnel_session) catre AMBELE destinatii separat - catre colector, unde
devine blob15 in Analytics Engine, si catre worker-ul aibaza-leads, unde
devine coloana session_id din tabela D1 leads. Cele doua sisteme nu se
citesc unul pe altul si nu deriva identificatorul unul din celalalt - il scriu
independent, la momente diferite ale aceleiasi cereri HTTP. Exact genul de
cheie comuna "legitima si existenta" pe care merita sa te bazezi, fara sa
inventezi o extensie noua.
Fix-ul a fost sa interoghez D1 read-only prin API-ul Cloudflare de query
(acelasi CLOUDFLARE_API_TOKEN deja folosit pentru Analytics Engine, doar alt
endpoint), filtrat pe client_code='aibaza', is_test=0, spam=0 si
session_id nevid, si sa construiesc un Set de session_id-uri reale. Acel
set devine completedIds pentru buildAggregateReport, care deja stia sa
numere completari per cohorta - doar ca nimeni nu-i dadea vreodata datele.
suspect nu exclude nimic: schema il documenteaza explicit ca informativ, nu
blocant (un om cu adblock arata identic cu un bot la Turnstile).
Proba controlata a fost read-only, fara niciun lead comercial fals: singurul
rand din leads cu session_id populat pentru aiBaza e un lead de test
(is_test=1, deci exclus corect de filtrul din reconciliere). L-am folosit ca
sa verific ca legatura chiar functioneaza - am interogat Analytics Engine
direct pentru acelasi session_id si am gasit evenimentul cerere_submitted
la exact aceeasi secunda din ts. Identificatorul scris independent in doua
sisteme diferite chiar se potriveste. Testele unitare acopera separat logica
de reconciliere (completedIds populat -> numarator completed corect,
completedIds gol -> tot read_only_aggregate, nu regreseaza la
context-only) si contractul HTTP catre D1 (SQL strict SELECT, fara
INSERT/UPDATE/DELETE, eroare descriptiva la esec HTTP - fail-loud, nu
fail-open silentios).
Readback-ul live pe 7/30/90 arata azi mode: "read_only_aggregate" in loc de
read_only_aggregate_context pe toate cele trei ferestre - mecanismul chiar
consulta sursa de adevar acum. completed: 0 alaturi de cerere_submitted: 0
in fereastra curenta nu e un bug: pur si simplu nu exista inca vreo cerere
reala (non-test) cu session_id in aceasta perioada, la fel cum a raportat si
auditul independent. Diferenta fata de inainte e ca acum raportul chiar poate
sa spuna asta cu autoritate, in loc sa taca pentru ca nu se uita nicaieri.
Lectia care ramane: cand doi cititori de audit intreaba "exista o cheie comuna legitima sau trebuie inventata una", raspunsul corect e sa cauti mai intai in codul care scrie in ambele sisteme, nu in schema care le citeste. De multe ori identificatorul exista deja - a fost doar scris in doua locuri fara ca nimeni sa lege explicit cele doua capete.