SQLite యొక్క LIKE ప్యాటర్న్‌లపై ఉన్న ఒక దాగి ఉన్న 50-బైట్ పరిమితి కారణంగా, Agentic Inbox ప్రాజెక్ట్ పొడవైన ఈమెయిల్ సబ్జెక్ట్‌లను వెతకడానికి ప్రయత్నించినప్పుడు Cloudflare Workers క్రాష్ అయ్యాయి. సెర్చ్ స్ట్రింగ్‌లను 48 అక్షరాలకు పరిమితం చేయడం వల్ల ఈ సమస్యలు నిలిచిపోయాయి.

ఎడ్జ్ రన్‌టైమ్‌ను దెబ్బతీసింది ఏమిటి

Agentic Inbox ప్రతి మెయిల్‌బాక్స్‌ను Cloudflare Durable Object లోపల రన్ చేస్తుంది, స్టోరేజ్ కోసం ఎంబెడెడ్ SQLite డేటాబేస్‌ను ఉపయోగిస్తుంది. AI-ఆధారిత ఏజెంట్ %search_term% రూపంలో సెర్చ్ ప్యాటర్న్‌ను నిర్మిస్తుంది. SQLite యొక్క LIKE ప్యాటర్న్ మొత్తం పొడవుపై 50-బైట్ల కఠినమైన పరిమితిని విధిస్తుంది. వినియోగదారు 48 అక్షరాల కంటే ఎక్కువ పొడవైన సబ్జెక్ట్‌ను నమోదు చేసినప్పుడు, చుట్టూ ఉన్న % గుర్తులు ఆ ప్యాటర్న్‌ను ఆ పరిమితి దాటి వెళ్లేలా చేశాయి. దీనివల్ల SQLite ఒక అన్‌హ్యాండెల్డ్ రన్‌టైమ్ ఎర్రర్‌ను ఇచ్చింది, దీనిని పరిమితమైన Worker ఎన్విరాన్‌మెంట్ ఒక ఫేటల్ (fatal) ఎర్రర్‌గా పరిగణించింది. దీనితో మొత్తం స్క్రిప్ట్ ఆగిపోయి, ఇన్‌బాక్స్ ఉపయోగించలేని స్థితికి చేరుకుంది మరియు AI ఏజెంట్ కూడా పనిచేయడం ఆగిపోయింది.

ఈ బగ్ ఎలా కనుగొనబడింది

Sentry, Workers నుండి వచ్చిన అన్‌క్యాచ్డ్ ఎక్సెప్షన్లను (uncaught exceptions) లాగ్ చేసింది. క్రాష్ జరిగినప్పుడు, SQLite ఎర్రర్‌ను ఎక్కడ ఇచ్చిందో Sentry ఖచ్చితమైన లైన్‌ను రికార్డ్ చేసింది. దానిలోని “Seer AI” ఫీచర్ స్టాక్ ట్రేస్‌ను విశ్లేషించి, LIKE ప్యాటర్న్ నిర్మాణాన్ని హైలైట్ చేసి, ప్యాటర్న్ పొడవే ఈ సమస్యకు కారణమని సూచించింది. SQLite యొక్క కంపైల్-టైమ్ డాక్యుమెంటేషన్‌ను తనిఖీ చేయగా 50-బైట్ల పరిమితి ఉన్నట్లు నిర్ధారణ అయ్యింది. ఆపై టీమ్ Geminiని ఉపయోగించి ఆ పరిమితిని ధృవీకరించి, యూజర్ ఇన్‌పుట్ కోసం సురక్షితమైన గరిష్ట పొడవును లెక్కించింది.

ఖచ్చితమైన పరిష్కారం

ఈ సమస్య పరిష్కారానికి ఇప్పటికే ఉన్న సెర్చ్ రూటీన్‌లో మూడు చిన్న మార్పులు అవసరమయ్యాయి:

  • వచ్చే ప్రతి సెర్చ్ టర్మ్‌పై 48 అక్షరాల కఠినమైన పరిమితిని విధించడం.
  • % వైల్డ్‌కార్డ్‌లను కలపడానికి ముందే ఇన్‌పుట్ స్ట్రింగ్‌ను ఆ పొడవుకు తగ్గించడం (slice చేయడం).
  • కొత్త లైబ్రరీలను జోడించకుండా, సెర్చ్ ఖచ్చితత్వాన్ని కాపాడుతూ మిగిలిన క్వరీని యథాతథంగా ఉంచడం.

ఈ సర్దుబాటు క్వరీ SQLiteకి చేరుకోకముందే జరుగుతుంది కాబట్టి, ఫైనల్ ప్యాటర్న్ ఎప్పుడూ 50-బైట్ల పరిమితిని దాటదు మరియు Worker మళ్ళీ క్రాష్ కాదు. ఎటువంటి అదనపు డిపెండెన్సీలను జోడించలేదు, కాబట్టి కోడ్‌బేస్ తేలికగా (lightweight) ఉంటుంది.

ఇది ఎందుకు ముఖ్యం

తక్కువ లాటెన్సీ (low-latency) అవసరాల కోసం ఎడ్జ్-హోస్టెడ్ డేటాబేస్‌లు ఆకర్షణీయంగా ఉంటాయి, కానీ అవి ఆన్-ప్రిమిసెస్ వెర్షన్‌ల మాదిరిగానే కొన్ని పరిమితులను కలిగి ఉంటాయి. రన్‌టైమ్ ఏదైనా అన్‌క్యాచ్డ్ ఎక్సెప్షన్‌ను ఫేటల్ (fatal) గా పరిగణించినప్పుడు, తెలియని కంపైల్-టైమ్ పరిమితి ప్రొడక్షన్ స్థాయిని దెబ్బతీసే బగ్‌గా మారవచ్చు. ఇక్కడ, పొడవైన సబ్జెక్ట్ లైన్‌ను టైప్ చేసిన ఏ వినియోగదారుడికైనా AI-ఆధారిత ఈమెయిల్ అసిస్టెంట్ పనిచేయకుండా ఈ క్రాష్ కారణమైంది—ఇది యూజర్ ఎక్స్‌పీరియన్స్ మరియు సర్వర్‌లెస్ ప్లాట్‌ఫారమ్‌ల విశ్వసనీయతపై ప్రత్యక్ష ప్రభావం చూపింది.

వేరే విధంగా ఏమి చేయవచ్చు ఉండేది

ఈ పరిష్కారం సరళంగానే ఉంది, కానీ ఇది ఒక మిస్ అయిన వాలిడేషన్ దశను గుర్తుచేస్తుంది. SQL స్ట్రింగ్‌ను నిర్మించడానికి ముందే ప్యాటర్న్ పొడవును తనిఖీ చేసే ఇన్‌పుట్ శానిటైజేషన్ (Input sanitization) ఉంటే, ఈ సమస్య ప్రొడక్షన్‌లో కాకుండా డెవలప్‌మెంట్ దశలోనే బయటపడేది.

తదుపరి జాగ్రత్తలు

ఎడ్జ్ రన్‌టైమ్‌లలో SQLiteని ఉపయోగించే డెవలపర్లు ప్యాటర్న్ మ్యాచింగ్‌కు సంబంధించిన అన్ని క్వరీ నిర్మాణాలను, ముఖ్యంగా వైల్డ్‌కార్డ్‌లు లేదా ఎస్కేప్ క్యారెక్టర్లను (escape characters) జోడించే వాటిని తనిఖీ చేయాలి. SQLite ఎక్కడ విఫలమైందో Sentry ఖచ్చితమైన లైన్‌ను గుర్తించింది. ఎడ్జ్ కంప్యూటింగ్ ప్రాచుర్యం పొందుతున్న కొద్దీ, దాగి ఉన్న ప్లాట్‌ఫారమ్ పరిమితులు తరచుగా ఎదురవుతాయి, కాబట్టి డాక్యుమెంట్ చేయబడిన పరిమితులకు అనుగుణంగా ఇన్‌పుట్‌లను వాలిడేట్ చేసే అలవాటు ఎంతో ఉపయోగపడుతుంది.

ముఖ్య గమనిక: SQLite LIKE ప్యాటర్న్‌లపై ఉన్న 50-బైట్ల పరిమితి Cloudflare Workersను క్రాష్ చేయవచ్చు, కానీ సెర్చ్ టర్మ్‌లను 48 అక్షరాలకు తగ్గించడం వల్ల ఎటువంటి అదనపు భారం లేకుండా ఈ లోపాన్ని తొలగించవచ్చు—ఒక చిన్న వాలిడేషన్ దశ ఎడ్జ్ సర్వీసులను స్థిరంగా ఉంచగలదని దీని ద్వారా నిరూపితమైంది.