FastAPI සහ Resend භාවිතා කරමින් බහු‑ගනුදෙනුකරු (multi‑tenant) ඊ‑මේල් සේවාවක් නිර්මාණය කරන අතරතුර, ලේඛන පරීක්ෂණ සහ කේත සමාලෝචන සියල්ල පසුබැසීමක් නැතිව පසු, අහෝසි වීමක් සිදු වුණා. එය බවුන්ස් (bounce) වෙබ්හුක් හෑන්ඩලර් එකේ ඇති බග් එකක් නිසා, එකම ඊ‑මේල් ලිපිනය ගොඩක් ගනුදෙනුකරුවන්ගේ සබ්ස්ක්රයිබර් ලැයිස්තුවේ පෙනෙන්නෙත්, එකවරම සියලුම ලියාපදිංචි අය අහෝසි කරලා.
මෙම සේවාවෙහි Contact වගුවේ email තීරුව පාරිභෝගික ID (customer_id) සමඟ සම්බන්ධ කර ඇති නමුත්, ගෝලීය තට්ටුවේ ඒකකයක් ලෙස අද්විතීය (unique) නොවේ. එමනිසා [email protected] වැනි ලිපිනය A ගනුදෙනුකරුගේ වගුවේද, B ගනුදෙනුකරුගේ වගුවේද තිබිය හැක. බවුන්ස් සිදු වූ විට, වෙබ්හුක් පණිවුඩයෙන් ලැබෙන to ලේඛනය පමණක් භාවිතා කර Contact වගුවේ email අඩංගු සියලුම පේළි is_subscribed = false කරනු ලැබීය.
මෙම ක්රියාවලියේ වැරැද්ද වන්නේ customer_id පරීක්ෂාව අඩාල වීමයි. එම නිසා, A ගනුදෙනුකරුගේ ඊ‑මේල් බවුන්ස් වුවත්, B ගනුදෙනුකරුගේ ඒම ලිපිනයත් අහෝසි වුණා. පරීක්ෂණ කේතය සහ පරීක්ෂණ නිරූපණ (unit tests) මේ තත්ත්වය අමතක කර තිබූ නිසා, බග් එක දිගටම පවත්නා තත්ත්වයක් බවට පත්වුණා.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික සමාජයට මෙය වැදගත් පණිවිඩයක්. පළමු වරට, බහු‑ගනුදෙනුකරු (multi‑tenant) ආකෘතිකරණය කරන වෙබ් යෙදුම් නිර්මාණයේ දත්ත වෙන්වීමේ (data isolation) වැදගත්කම තේරුම් ගැනීමට අවශ්යය. සාර්ථක ආරක්ෂක සැලසුම් සහිතව, customer_id පරීක්ෂාවක් නොකළ විට, අනිවාර්යයෙන්ම තවත් ගනුදෙනුකරුගේ දත්ත විනාශ විය හැක.
- සිසුන්ට, සබ්ස්ක්රයිබර් කළමනාකරණය සහ වෙබ්හුක් ප්රතිචාර (webhook callbacks) සැකසීමේදී සත්ය පරීක්ෂණ ලිවිය හැක.
- ඩිවෙලපර්ලාට, ORM (Object‑Relational Mapping) භාවිතා කරන විට unique constraints සහ multi‑tenant filters සලකා බලන්න මතක් කරයි.
- ව්යාපාරිකයන්ට, පාරිභෝගික විශ්වාසය සහ එමෙන්ම ඊ‑මේල් ප්රේරක (email deliverability) රැක ගැනීමට ආරක්ෂක නීති මැනවින් අනුගමනය කිරීමේ අවශ්යතාවය පෙන්වයි.
අවසන් වශයෙන්, මෙම බග් එකේ නිවැරදි හඳුනා ගැනීම හා නවීකරණය, දැනටමත් ක්ලවුඩ්‑නැති (cloud‑native) සේවාවන්හි අධික පාරිභෝගික විශ්වාසය රැක ගැනීමට මූලික පියවරක් වේ.
ඉදිරියට, ඕනෑම බහු‑ගනුදෙනුකරු පද්ධතියක් නිර්මාණය කරන විට, tenant‑aware queries සහ database constraints සලකා බැලීම අත්යවශ්ය වේ.
