সাইটের পাবলিশিং প্ল্যাটফর্মে চালানো একটি ক্লিনআপ স্ক্রিপ্ট ভুলবশত কোড স্নিপেটগুলোকে ত্রুটিপূর্ণ Liquid ভেরিয়েবল হিসেবে শনাক্ত করে এবং যে সমস্ত আর্টিকেলে সেগুলো ছিল, সেখান থেকে মুছে ফেলে। এই ত্রুটির কারণে ডজন ডজন টেকনিক্যাল পোস্ট থেকে উদাহরণস্বরূপ কোডগুলো হারিয়ে যায়, যা পাঠকদের জন্য অত্যন্ত গুরুত্বপূর্ণ ছিল। এর ফলে জরুরি ভিত্তিতে রোলব্যাক করতে হয় এবং কনটেন্ট মাইগ্রেশন কীভাবে পরীক্ষা করা হবে তা নিয়ে নতুন করে ভাবার প্রয়োজন পড়ে।

কীভাবে এই বাগটি এড়িয়ে গেল

প্ল্যাটফর্মটি Liquid ব্যবহার করে, যা একটি টেমপ্লেটিং ল্যাঙ্গুয়েজ এবং এটি {{ … }} এর মতো ট্যাগ ব্যবহার করে ডাইনামিক কনটেন্ট মার্কআপ করে। একটি রুটিন রক্ষণাবেক্ষণ কাজের লক্ষ্য ছিল এমন কিছু অপ্রয়োজনীয় ট্যাগ বাদ দেওয়া যা রেন্ডারিংয়ে সমস্যা করতে পারে। স্ক্রিপ্টের পার্সারটি এমন ওপেনিং ট্যাগ খুঁজছিল যেগুলোর বিপরীতে কোনো ক্লোজিং ট্যাগ ছিল না এবং যখনই এটি কোনো ট্যাগ খুঁজে পেত, ত্রুটিটি "ঠিক" করার জন্য পুরো ব্লকটিই মুছে ফেলত।

বাস্তবে, পার্সারটি কোড ব্লকগুলোকে ঘিরে থাকা {% raw %} এবং {% endraw %} ট্যাগগুলোকে চিনতে ব্যর্থ হয়। এই ট্যাগগুলো Liquid-কে নির্দেশ দেয় যে এর ভেতরে থাকা সবকিছুকে সাধারণ টেক্সট হিসেবে গণ্য করতে, কিন্তু ত্রুটিপূর্ণ স্ক্রিপ্টটি ওপেনিং {% raw %} ট্যাগটিকে একটি অসম্পূর্ণ ভেরিয়েবল ({{% raw %}) হিসেবে গণ্য করে এবং এর চারপাশের কোডটি মুছে ফেলে। লগ করা ত্রুটি বার্তাটি ছিল:

Liquid syntax error: Variable '{{% raw %}' was not properly terminated.

যেহেতু স্ক্রিপ্টটি সরাসরি লাইভ কনটেন্ট রিপোজিটরিতে কাজ করছিল, তাই এই মুছে ফেলার প্রক্রিয়াটি একযোগে ঘটে এবং মাত্র একবার চালানোর মাধ্যমেই সমস্ত আক্রান্ত আর্টিকেল থেকে কোড উদাহরণগুলো মুছে যায়।

ঝুঁকির বিষয়গুলো কী কী

টেকনিক্যাল আর্টিকেলগুলো ধারণা ব্যাখ্যা করতে, ফলাফল পুনরায় তৈরি করতে এবং পাঠকদের ধাপে ধাপে পদ্ধতি অনুসরণ করতে সাহায্য করার জন্য কোড স্নিপেটের ওপর নির্ভর করে। এই ব্লকগুলো হারিয়ে যাওয়ার ফলে পোস্টগুলো অনেকাংশেই অকেজো হয়ে পড়ে, লেখকদের পুনরায় কনটেন্ট লিখতে বাধ্য করে এবং প্ল্যাটফর্মের নির্ভরযোগ্যতার ওপর মানুষের আস্থা কমিয়ে দেয়। যে সাইট উচ্চমানের ডেভেলপার ডকুমেন্টেশনের ওপর ভিত্তি করে তাদের সুনাম তৈরি করে, তাদের জন্য এই ঘটনাটি পাঠকসংখ্যা এবং কন্ট্রিবিউটরদের আস্থা—উভয়কেই হুমকির মুখে ফেলে।

যে বিষয়গুলো বেশিরভাগ পাঠক খেয়াল করেননি

  • স্যান্ডবক্সিং ছাড়া ব্যাচ প্রসেসিং – স্ক্রিপ্টটি কোনো স্টেজিং কপি ব্যবহার না করে সরাসরি প্রোডাকশন ডেটার ওপর চালানো হয়েছিল।
  • অপ্রতুল ট্যাগ হ্যান্ডলিং – শুধুমাত্র কিছু নির্দিষ্ট Liquid ট্যাগ বিবেচনা করা হয়েছিল; {% raw %} ট্যাগটি হোয়াইটলিস্টে অন্তর্ভুক্ত ছিল না।
  • ইনক্রিমেন্টাল টেস্টিংয়ের অভাব – ছোট কোনো স্যাম্পলের ওপর পাইলট রান না করেই পুরো ডেটাসেটের ওপর কাজটি প্রয়োগ করা হয়েছিল।

যা দিয়ে এটি প্রতিরোধ করা যেত

  • কপির ওপর মাইগ্রেশন চালানো – যেকোনো বাল্ক ট্রান্সফরমেশন বা বড় পরিবর্তনের ক্ষেত্রে প্রথমে ডেটাবেসের একটি স্যান্ডবক্সড ভার্সনে তা প্রয়োগ করুন।
  • সব ধরনের ট্যাগ ভ্যারিয়েশনের বিপরীতে পার্সার ইউনিট-টেস্ট করা – এতে raw ব্লক, কমেন্ট ট্যাগ এবং নেস্টেড স্ট্রাকচারের মতো এজ কেসগুলো অন্তর্ভুক্ত করুন।
  • ধীরে ধীরে প্রয়োগ (Gradual rollout) – প্রথমে সীমিত সংখ্যক আর্টিকেল প্রসেস করুন, ফলাফল যাচাই করুন এবং তারপর বড় পরিসরে কাজ শুরু করুন।

পাল্টা যুক্তি

কেউ কেউ যুক্তি দেন যে, দ্রুত পরিবর্তনশীল সাইটগুলোর জন্য প্রতিটি স্ক্রিপ্ট একটি ফুল ব্যাকআপে পরীক্ষা করা অবাস্তব, এবং দ্রুত সমাধানের প্রয়োজনীয়তা ডেটা হারানোর ঝুঁকির চেয়ে বেশি গুরুত্বপূর্ণ। যদিও গতি গুরুত্বপূর্ণ, তবে একটি বড় মাপের ডিলিটেশন বা মুছে ফেলা পুনরায় ঠিক করার খরচ—ডেভেলপারের সময় এবং সুনামের ক্ষতির উভয় দিক থেকেই—সতর্কভাবে কাজ করার ফলে যে বিলম্ব হয়, তার চেয়ে অনেক বেশি হতে পারে।

পরবর্তী পদক্ষেপ

টিমটি ব্যাকআপ থেকে হারিয়ে যাওয়া কোডগুলো পুনরুদ্ধার করেছে এবং সমস্ত Liquid কনস্ট্রাকশন শনাক্ত করার জন্য ক্লিনআপ টুলটি সংশোধন করছে। তারা একটি পোস্ট-মর্টেম প্রকাশ করার পরিকল্পনা করছে যেখানে আপডেট করা টেস্টিং ওয়ার্কফ্লো বিস্তারিতভাবে জানানো হবে, এবং সংশোধিত স্ক্রিপ্টটি জনসমক্ষে শেয়ার করবে যাতে অন্যান্য পাবলিশাররা একই ভুল এড়াতে পারেন। এই ঘটনাটি একটি সতর্কবার্তা হিসেবে কাজ করে: একটি সামান্য পার্সিং ত্রুটিও লেখকের কয়েক সপ্তাহের পরিশ্রম মুছে ফেলতে পারে, যা কঠোর টেস্টিং বা পরীক্ষা করাকে অপরিহার্য করে তোলে।