SQLite ਦੇ LIKE patterns 'ਤੇ ਇੱਕ ਲੁਕਵੀਂ 50-ਬਾਈਟ ਦੀ ਸੀਮਾ ਕਾਰਨ Cloudflare Workers ਕ੍ਰੈਸ਼ ਹੋ ਗਏ ਸਨ ਜਦੋਂ Agentic Inbox ਪ੍ਰੋਜੈਕਟ ਨੇ ਲੰਬੇ ਈਮੇਲ ਵਿਸ਼ਿਆਂ (subjects) ਨੂੰ ਸਰਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਅਤੇ ਸਰਚ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ 48 ਅੱਖਰਾਂ ਤੱਕ ਸੀਮਤ ਕਰਨ ਨਾਲ ਇਹ ਸਮੱਸਿਆਵਾਂ ਰੁਕ ਗਈਆਂ।

ਕੀ ਚੀਜ਼ ਨੇ edge runtime ਨੂੰ ਖਰਾਬ ਕੀਤਾ

Agentic Inbox ਹਰੇਕ ਮੇਲਬਾਕਸ ਨੂੰ Cloudflare Durable Object ਦੇ ਅੰਦਰ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਸਟੋਰੇਜ ਲਈ ਇੱਕ embedded SQLite database ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। AI-driven agent ਇੱਕ ਸਰਚ ਪੈਟਰਨ %search_term% ਵਜੋਂ ਬਣਾਉਂਦਾ ਹੈ। SQLite ਇੱਕ LIKE pattern ਦੀ ਕੁੱਲ ਲੰਬਾਈ 'ਤੇ 50-ਬਾਈਟ ਦੀ ਸਖ਼ਤ ਸੀਮਾ (ceiling) ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੇ 48 ਅੱਖਰਾਂ ਤੋਂ ਵੱਧ ਲੰਬਾ ਵਿਸ਼ਾ (subject) ਦਰਜ ਕੀਤਾ, ਤਾਂ ਆਲੇ-ਦੁਆਲੇ ਦੇ % ਚਿੰਨ੍ਹਾਂ ਨੇ ਪੈਟਰਨ ਨੂੰ ਉਸ ਸੀਮਾ ਤੋਂ ਪਾਰ ਕਰ ਦਿੱਤਾ। SQLite ਨੇ ਇੱਕ unhandled runtime error ਦਿੱਤਾ, ਜਿਸ ਨੂੰ ਸੀਮਤ Worker environment ਨੇ fatal ਮੰਨ ਲਿਆ। ਪੂਰਾ ਸਕ੍ਰਿਪਟ ਖਤਮ ਹੋ ਗਿਆ, ਜਿਸ ਨਾਲ inbox ਵਰਤੋਂ ਦੇ ਅਯੋਗ ਹੋ ਗਿਆ ਅਤੇ AI agent ਵੀ ਖਰਾਬ ਹੋ ਗਿਆ।

ਬੱਗ (bug) ਦਾ ਪਤਾ ਕਿਵੇਂ ਲੱਗਿਆ

Sentry ਨੇ Workers ਤੋਂ uncaught exceptions ਨੂੰ log ਕੀਤਾ। ਜਦੋਂ ਕ੍ਰੈਸ਼ ਹੋਇਆ, Sentry ਨੇ ਉਸ ਸਹੀ ਲਾਈਨ ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ ਜਿੱਥੇ SQLite ਨੇ ਗਲਤੀ (error) ਦਿੱਤੀ ਸੀ। ਇਸਦੇ “Seer AI” ਫੀਚਰ ਨੇ stack trace ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ, LIKE pattern ਦੇ ਬਣਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ, ਅਤੇ ਪੈਟਰਨ ਦੀ ਲੰਬਾਈ ਨੂੰ ਮੁੱਖ ਕਾਰਨ ਵਜੋਂ ਦੱਸਿਆ। SQLite ਦੇ compile-time documentation ਦੀ ਇੱਕ ਝਲਕ ਨੇ 50-ਬਾਈਟ ਦੀ ਪਾਬੰਦੀ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ, ਅਤੇ ਟੀਮ ਨੇ ਇਸ ਸੀਮਾ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਉਪਭੋਗਤਾ ਇਨਪੁਟ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵੱਧ ਤੋਂ ਵੱਧ ਲੰਬਾਈ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ Gemini ਦੀ ਵਰਤੋਂ ਕੀਤੀ।

ਸਟੀਕ ਸੁਧਾਰ (The surgical fix)

ਇਸ ਦੇ ਹੱਲ ਲਈ ਮੌਜੂਦਾ ਸਰਚ ਰੁਟੀਨ ਦੇ ਅੰਦਰ ਤਿੰਨ ਛੋਟੇ ਬਦਲਾਅ ਕਰਨ ਦੀ ਲੋੜ ਸੀ:

  • ਕਿਸੇ ਵੀ ਆਉਣ ਵਾਲੇ ਸਰਚ ਟਰਮ 'ਤੇ 48 ਅੱਖਰਾਂ ਦੀ ਸਖ਼ਤ ਸੀਮਾ ਲਗਾਓ।
  • % wildcards ਨੂੰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁਟ ਸਟ੍ਰਿੰਗ ਨੂੰ ਉਸ ਲੰਬਾਈ ਤੱਕ ਕੱਟੋ (slice)।
  • ਬਾਕੀ ਕੁਐਰੀ (query) ਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਰੱਖੋ, ਤਾਂ ਜੋ ਨਵੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜੋੜੇ ਬਿਨਾਂ ਸਰਚ ਦੀ ਸ਼ੁੱਧਤਾ ਬਣੀ ਰਹੇ।

ਕਿਉਂਕਿ ਇਹ ਫ਼ਰਦ (adjustment) ਕੁਐਰੀ ਦੇ SQLite ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਅੰਤਿਮ ਪੈਟਰਨ ਕਦੇ ਵੀ 50-ਬਾਈਟ ਦੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ Worker ਹੁਣ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੁੰਦਾ। ਕੋਈ ਵਾਧੂ dependencies ਨਹੀਂ ਜੋੜੀਆਂ ਗਈਆਂ, ਇਸ ਲਈ codebase ਹਲਕਾ (lightweight) ਰਹਿੰਦਾ ਹੈ।

ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Edge-hosted databases ਘੱਟ-ਲੇਟੈਂਸੀ (low-latency) ਵਾਲੇ ਮਾਮਲਿਆਂ ਲਈ ਆਕਰਸ਼ਕ ਹਨ, ਪਰ ਉਹ on-premises ਵਰਜ਼ਨਾਂ ਵਾਂਗ ਹੀ ਉਹੀ ਸੀਮਾਵਾਂ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਅਣਪਛਾਤੀ compile-time ਸੀਮਾ ਇੱਕ production-blocking bug ਬਣ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੋਈ runtime ਕਿਸੇ ਵੀ uncaught exception ਨੂੰ fatal ਮੰਨ ਲੈਂਦਾ ਹੈ। ਇੱਥੇ, ਕ੍ਰੈਸ਼ ਨੇ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਉਪਭੋਗਤਾ ਲਈ AI-powered ਈਮੇਲ ਸਹਾਇਕ (assistant) ਦੇ ਕੰਮ ਕਰਨ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਜਿਸਨੇ ਲੰਬੀ subject line ਲਿਖੀ ਸੀ—ਜੋ ਕਿ user experience ਅਤੇ serverless platforms ਦੇ ਭਰੋਸੇਮੰਦ ਹੋਣ ਦੇ ਵਾਅਦੇ 'ਤੇ ਸਿੱਧੀ ਚੁਣੌਤੀ ਸੀ।

ਕੀ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ

ਸੁਧਾਰ ਸਿੱਧਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਰੁਕੀ ਹੋਈ validation ਸਟੈਪ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। Input sanitization, ਜੋ SQL string ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਟਰਨ ਦੀ ਲੰਬਾਈ ਦੀ ਜਾਂਚ ਕਰਦਾ, ਇਸ ਸਮੱਸਿਆ ਨੂੰ production ਦੀ ਬਜਾਏ development ਦੌਰਾਨ ਹੀ ਫੜ ਲੈਂਦਾ।

ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ

Edge runtimes 'ਤੇ SQLite ਨੂੰ ਤੈਨਾਤ (deploy) ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹਨਾਂ ਸਾਰੀਆਂ query constructions ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ pattern matching ਸ਼ਾਮਲ ਹੈ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਵਿੱਚ ਜੋ wildcards ਜਾਂ escape characters ਜੋੜਦੇ ਹਨ। Sentry ਨੇ ਉਸ ਸਹੀ ਲਾਈਨ ਨੂੰ ਫੜ ਲਿਆ ਜਿੱਥੇ SQLite ਅਸਫਲ ਰਿਹਾ। ਜਿਵੇਂ-ਜਿਵੇਂ edge computing ਦਾ ਪ੍ਰਭਾਵ ਵਧ ਰਿਹਾ ਹੈ, ਲੁਕੀਆਂ ਹੋਈਆਂ ਪਲੇਟਫਾਰਮ ਸੀਮਾਵਾਂ ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆਉਣਗੀਆਂ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ (documented) ਸੀਮਾਵਾਂ ਦੇ ਵਿਰੁੱਧ ਇਨਪੁਟ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਆਦਤ ਫਾਇਦੇਮੰਦ ਸਿੱਧ ਹੋਵੇਗੀ।

ਸਿੱਖਿਆ (Takeaway): SQLite LIKE patterns 'ਤੇ 50-ਬਾਈਟ ਦੀ ਸੀਮਾ Cloudflare Workers ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਸਰਚ ਟਰਮਾਂ ਨੂੰ 48 ਅੱਖਰਾਂ ਤੱਕ ਸੀਮਤ ਕਰਨ ਨਾਲ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਬੋਝ ਦੇ ਇਸ ਖਰਾਬੀ ਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਇਹ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਹੈ ਕਿ ਇੱਕ ਛੋਟਾ ਜਿਹਾ validation ਸਟੈਪ edge services ਨੂੰ ਸਥਿਰ ਰੱਖ ਸਕਦਾ ਹੈ।