.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
TimeoutError: waiting for selector 20টির মধ্যে 14 নম্বর ধাপে
সেশন বিনামূল্যে — মূল্য দিন শুধু ট্রাফিকের জন্য
UI মোডসহ ক্লাউড ব্রাউজার
ঠিক সেই সেশনটিই একটি আসল ব্রাউজার ট্যাবে খুলে সরাসরি দেখুন। গোলমালের মুহূর্তে পেজ যে অবস্থায় ছিল, আপনি ঠিক সেটাই দেখতে পাবেন।
- ব্যর্থতা পুনরায় ঘটাতে পুরো কাজটি আবার চালানোর বদলে চলমান সেশনের লাইভ ভিউ খুলুন
- কঠিন CAPTCHA বা অপ্রত্যাশিত 2FA প্রম্পট একজন মানুষের হাতে দিন, তারপর স্ক্রিপ্টকে আবার সংযুক্ত হতে দিন
- কুকি ও পেজের অবস্থা যেমন ছিল তেমনই থাকে — শুধু সংযোগ বদলায়
UI মোড
সেশনটি একটি আসল
ব্রাউজারে খুলুন।
যেকোনো চলমান সেশন লাইভ ভিউতে খোলা যায়: স্ক্রিপ্ট যে ব্রাউজারটি চালাচ্ছিল, সেটিই আপনার নিজের ট্যাবে। স্ক্রিপ্ট যা পারে না তা নিজে ক্লিক করে পার করুন, তারপর আবার স্ক্রিপ্টের হাতে ফিরিয়ে দিন।
ক্লাউড ব্রাউজারে UI মোড কেন গুরুত্বপূর্ণ
মাঝপথে ভেঙে যাওয়া হেডলেস স্ক্রিপ্ট সাধারণত শুধু একটা স্ট্যাক ট্রেস দেয়, বড়জোর একটা লাইন নম্বর। বিশ ধাপের চোদ্দ নম্বর ধাপে কোন ক্লিকটা আসলে লক্ষ্যভ্রষ্ট হলো, কিংবা পেজটা ঠিকভাবে লোড হয়েছিল কি না, তা বের করা বেশ কঠিন।
UI মোডসহ ক্লাউড ব্রাউজার আপনাকে দেয় দ্বিতীয় একটি উপায়: ঠিক সেই সেশনটিই একটি আসল ব্রাউজার ট্যাবে খুলে সরাসরি দেখুন। গোলমালের মুহূর্তে পেজ যে অবস্থায় ছিল, আপনি সেটাই দেখতে পাবেন – পরে কনসোল আউটপুট জোড়া দিয়ে অনুমান করতে হবে না, স্পষ্ট ত্রুটির বার্তার আশায় পুরো কাজটি পাঁচবার চালাতেও হবে না।
অতিরিক্ত ধাপওয়ালা লগইন, আগের উত্তরের ওপর নির্ভর করে বদলে যাওয়া ফর্ম এবং চেকআউট ফ্লোতে এটি সবচেয়ে বেশি কাজে আসে। মূলত যেকোনো জায়গায়, যেখানে হঠাৎ আসা একটি পপআপ নিঃশব্দে এমন স্ক্রিপ্ট ভেঙে দিতে পারে যা এক ঘণ্টা আগেও ঠিকঠাক চলছিল, আর সেই পপআপের জন্য কেউ আলাদা নিয়ম লেখেনি, কারণ কেউ তা আশা করেনি।
ভিজ্যুয়াল মোডের প্রধান বৈশিষ্ট্য
কেন প্রয়োজন, তার ওপর নির্ভর করে লাইভ ভিউ কয়েকটি আলাদা কাজ করে। কখনো লক্ষ্য একটা বাগ ধরা, কখনো সেটি পার হওয়া।
রিয়েল-টাইম স্ক্রিপ্ট ডিবাগিং (লাইভ ডিবাগিং)
আটকে যাওয়া বা ব্যর্থ রানের মানে সাধারণত সেশনটি মরে যাওয়া নয়। প্রায়ই সেটি তখনও সেখানেই থাকে, শুধু কোনো কিছুর সঙ্গে সংযুক্ত থাকে না। লাইভ ভিউ খুললে আপনি ব্যর্থতার মাঝখানেই সরাসরি সেটি দেখতে পান; লগ ফাইল দেখে অনুমান করতে হয় না যে ওই মুহূর্তে পেজটা কেমন ছিল।
যেসব সমস্যা কখনোই স্পষ্ট ত্রুটি দেখায় না, সেগুলোও এতে ধরা পড়ে – অর্ধেক লোড হওয়া পেজ, ক্লিকের নিচ থেকে বাটন সরিয়ে দেওয়া লেআউট শিফট, কিংবা আধা সেকেন্ড দেরিতে আসা মোডাল।
ইন্টারঅ্যাকটিভ সেশন নিয়ন্ত্রণ (হিউম্যান-ইন-দ্য-লুপ)
কিছু বিষয় স্ক্রিপ্ট নিজে পার করতে পারে না – কঠিন CAPTCHA, অপ্রত্যাশিত 2FA প্রম্পট, কিংবা এমন কোনো নিরাপত্তা যাচাই যার জন্য কেউ আগে থেকে পরিকল্পনা করেনি। তখন অটোমেশন সংযোগ বিচ্ছিন্ন হয়, একই সেশনের জন্য লাইভ ভিউ খোলে, আর কেউ ঝামেলার অংশটুকু হাতে ক্লিক করে পার করে দেয়।
এরপর স্ক্রিপ্ট আবার সংযুক্ত হয়ে সেখান থেকেই চলতে থাকে। কুকি, পেজের অবস্থা, সব কিছু যেমন ছিল তেমনই থাকে – শুধু সংযোগ বদলায়। অ্যান্টিডিটেক্ট সেটআপে চলা সেশনেও এটি সমান গুরুত্বপূর্ণ: যথেষ্ট বিশ্বাসযোগ্য ও শনাক্ত-অযোগ্য ফিঙ্গারপ্রিন্টের অ্যান্টিডিটেক্ট ব্রাউজারও এমন যাচাইয়ের সামনে পড়তে পারে যা শুধু একজন আসল মানুষই পার করতে পারে।
সেশন রেকর্ডিং ও স্ক্রিনশট
সেশন লাইভ দেখা তখনই কাজে আসে, যখন ঘটনার সময় আপনি সেখানে থাকেন। বেশিরভাগ ডিবাগিংয়ে শেষ পর্যন্ত পরে দেখার মতো কিছু লাগে – সমস্যা শুরুর মুহূর্তের একটি স্ক্রিনশট, পূর্ণ সেশন রেকর্ডিং, বা আসলে কী পাঠানো ও গ্রহণ করা হয়েছে তা যাচাইয়ের জন্য একটি নেটওয়ার্ক লগ।
সব ক্লাউড ব্রাউজার প্ল্যাটফর্ম এই তিনটি একইভাবে দেয় না, তাই নির্দিষ্ট কোনো ফরম্যাটকে ভিত্তি করে ওয়ার্কফ্লো সাজানোর আগে Floppydata-র কাছ থেকে সরাসরি জেনে নিন কী কী সমর্থিত। ব্যর্থতার ঠিক আগের একটি স্ক্রিনশটই প্রায়ই যথেষ্ট; আর যেসব কঠিন ক্ষেত্রে চোখে দেখা কিছুই ভুলটা ব্যাখ্যা করে না, সেখানে ভিডিও ও নেটওয়ার্ক লগ কাজে আসে।
এটি বাস্তবে কোথায় ব্যবহার হয়
কয়েকটি পরিস্থিতি বারবার সামনে আসে, যদিও ওপর থেকে দেখে সেগুলো সবসময় একরকম মনে হয় না:
-
সাইন-আপ ফ্লো ও চেকআউটে জালিয়াতি যাচাই
SMS ভেরিফিকেশনের আড়ালে থাকা সাইন-আপ ফ্লো, কিংবা মাঝে মাঝে জালিয়াতি যাচাই চালু করা চেকআউট পেজ – স্ক্রিপ্টে সামলানো ঝামেলার, কিন্তু একবার হাতে ক্লিক করে পার করা দ্রুত।
-
আসল বাগ ও অস্থির সিলেক্টরের পার্থক্য বোঝা
QA টিম পুরো স্যুট অন্ধভাবে আবার না চালিয়ে যাচাই করে দেখে, ব্যর্থ এন্ড-টু-এন্ড টেস্টটি আসল বাগ নাকি শুধু একটি অস্থির সিলেক্টর।
-
গ্রাহকের বর্ণনা করা সমস্যা পুনরায় ঘটানো
সাপোর্ট টিম এমন বাগ পুনরায় ঘটায়, যা গ্রাহক বর্ণনা করেছেন কিন্তু ঠিকভাবে স্ক্রিনশট নিতে পারেননি।
-
পেজ প্রত্যাশামতো রেন্ডার হয়েছে কি না নিশ্চিত করা
স্ক্র্যাপিং কাজে সিলেক্টরটিই ভাঙা ধরে নেওয়ার আগে নিশ্চিত করা হয় যে পেজ আসলে সিলেক্টরের প্রত্যাশামতো রেন্ডার হয়েছে।
-
লাইভ চলতে দেখানো
ক্লায়েন্ট ডেমো, যেখানে টার্মিনাল লগে ভরসা করতে বলার চেয়ে কিছু লাইভ চলতে দেখানোই বেশি কার্যকর।
আপনার স্ক্রিপ্টে UI / লাইভ ভিউয়ার কীভাবে চালু করবেন
একটি সেশনে একই সময়ে অটোমেশন সংযোগ ও লাইভ ভিউ চলতে পারে না। একটি বন্ধ করলে অন্যটির পথ খোলে, আর পরে ফিরে আসতে প্রায় ততটুকুই সময় লাগে যতটা সরে যেতে লেগেছিল:
- স্ক্রিপ্ট তার বর্তমান সেশন থেকে সংযোগ বিচ্ছিন্ন করে।
- সেই একই সেশনের জন্য লাইভ ভিউ অনুরোধ করা হয় এবং একটি ব্রাউজার ট্যাবে খোলা হয়।
- যা সামলানো দরকার, একজন মানুষ তা সামলান – একটি CAPTCHA, একটি 2FA কোড, বা একবারের সম্মতি স্ক্রিন।
- স্ক্রিপ্ট সেশনের সঙ্গে নতুন সংযোগ চায় এবং ঠিক যেখানে থেমেছিল সেখান থেকেই আবার শুরু করে।
live-view.js
await browser.close(); // hand off to a human// POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }// person opens liveViewUrl, solves the CAPTCHA / 2FA prompt// GET /v2/browser/sessions/{id} -> fresh connectUrl, script resumesconnectUrl ও liveViewUrl দুটিকেই পাসওয়ার্ডের মতো সামলান: কোথাও লগ করবেন না, সাপোর্ট টিকিটে পেস্ট করবেন না, এবং প্রয়োজনের বেশি সময় পুরোনো লিংক ধরে না রেখে নতুন লিংক অনুরোধ করুন।