Gemini Live-এ turnComplete মানেই শেষ নয়—ভুলে tool response হারাতে পারেন

Gemini 3.8 Live Extended Thinking-এ migration-এর মূল নিয়ম হলো: turnComplete=true পেলেই interaction শেষ করবেন না। Google-এর মডেল নির্দেশনা অনুযায়ী এটি শুধু চলতি spoken utterance-এর সীমা জানাতে পারে; background reasoning, tool call বা পরের audio frame তখনও বাকি থাকতে পারে।

তাই model ID বদলানোর পাশাপাশি receive loop, UI state ও tool executor বদলাতে হবে। client-কে interaction_status=IDLE না আসা পর্যন্ত শুনতে হবে, প্রতিটি custom function-কে NON_BLOCKING হিসেবে declare করতে হবে এবং turnComplete-এর পরে pending tool state অক্ষত রাখতে হবে—নইলে পরের call বা তার response হারানোর ঝুঁকি তৈরি হয়।

কোন Live মডেলে নতুন lifecycle প্রযোজ্য

Gemini 3.8 Live সরাসরি, কম-latency কথোপকথনের জন্য; Gemini 3.8 Live Extended Thinking জটিল বহু-ধাপের কাজ, background reasoning ও অপেক্ষাকৃত দীর্ঘ tool execution-এর জন্য। Gemini API release notes জানায়, দুটি audio-to-audio মডেলই ১৫ সেপ্টেম্বর ২০২৬-এ GA হয়েছে; Google প্রথমটিকে অধিকাংশ low-latency voice experience-এর default এবং দ্বিতীয়টিকে বেশি background reasoning দরকার এমন কাজের জন্য বর্ণনা করেছে।

Extended Thinking-এর setup-এ thinking_config দিয়ে low, medium বা high thinking_level দেওয়া যায়; MINIMAL সমর্থিত নয়। সব custom function declaration-এ behavior=NON_BLOCKING আবশ্যক। Blocking function call hard error দেয় এবং function-response scheduling configuration—যেমন INTERRUPT, WHEN_IDLE বা SILENT—এই মডেলে সমর্থিত নয়।

Client state machine-এর transition map

একটি isSpeaking boolean দিয়ে এই lifecycle নির্ভরযোগ্যভাবে বোঝানো যাবে না। অন্তত IDLE, AWAITING_SERVER, IN_PROGRESS এবং TOOL_RUNNING state রাখুন; interruption-কে আলাদা event হিসেবে প্রক্রিয়া করুন। Live API Thinking guide যে flow দেখায়, তাতে intermediate কথনের সঙ্গে turnComplete=true ও interactionStatus=IN_PROGRESS আসতে পারে; এরপর tool call ও tool response পেরিয়ে চূড়ান্ত উত্তরে interactionStatus=IDLE আসে।

• IDLE → AWAITING_SERVER: user input commit করার পরে request সক্রিয় হিসেবে চিহ্নিত করুন এবং receive loop চালু রাখুন।
• AWAITING_SERVER → IN_PROGRESS: interaction_status=IN_PROGRESS এলে reasoning, audio generation বা tool response-এর অপেক্ষা চলছে বলে ধরুন।
• IN_PROGRESS + turnComplete=true → IN_PROGRESS: চলতি utterance-এর playback boundary বন্ধ করুন; listener, pending call বা interaction state পরিষ্কার করবেন না।
• IN_PROGRESS + toolCall → TOOL_RUNNING: call ID, name ও args সংরক্ষণ করে কাজটি asynchronous task-এ পাঠান। receive loop অপেক্ষায় আটকে রাখবেন না।
• TOOL_RUNNING + response sent → IN_PROGRESS: একই call ID-সহ ফল পাঠিয়ে server-এর পরবর্তী message-এর অপেক্ষা করুন; স্থানীয়ভাবে IDLE ধরে নেবেন না।
• Active state + interaction_status=IDLE → IDLE: কেবল তখনই interaction শেষ করুন, UI-কে নতুন input-এর জন্য প্রস্তুত করুন এবং অস্থায়ী state পরিষ্কার করুন।

কোনো message-এ interaction_status না থাকলে আগের lifecycle state বজায় রাখুন। একই message-এর audio, tool call ও status—সব প্রাসঙ্গিক অংশ process করার পর UI transition প্রয়োগ করুন; status পড়েই handler থেকে return করলে অন্য অংশ বাদ পড়তে পারে।

Asynchronous tool-call loop-এর ছদ্ম-কোড

Receiver ও tool executor আলাদা রাখুন। pendingCalls map-এ call ID দিয়ে প্রতিটি কাজ চিহ্নিত করলে duplicate execution ঠেকানো এবং সঠিক response মেলানো সহজ হয়। Framework-নিরপেক্ষ flowটি এমন:

1. Connection খোলা থাকা পর্যন্ত প্রতিটি server message গ্রহণ করুন। turnComplete এলে শুধু utterance boundary নথিভুক্ত করুন।
2. Message-এর সব audio part playback queue-তে যোগ করুন এবং interactionStatus থাকলে latestStatus আপডেট করুন।
3. প্রতিটি functionCall-এর id, name ও args পড়ুন। ID আগে pendingCalls-এ থাকলে আবার execute করবেন না; না থাকলে নতুন entry তৈরি করুন।
4. Tool-টি background task বা worker queue-তে চালান। Receive callback-এর মধ্যে ফলের জন্য অপেক্ষা করে পরের server event আটকে রাখবেন না।
5. কাজ শেষ হলে connection এবং call entry এখনও বৈধ কি না দেখুন। Function response-এ server-এর দেওয়া একই id ও name রেখে result পাঠান; failure হলে application-নির্ধারিত structured error ফেরত দিন।
6. Response পাঠানো সফল হলে pending entry সরান, কিন্তু interaction state IN_PROGRESS রাখুন। চূড়ান্ত transition-এর জন্য server-এর IDLE status অপেক্ষা করুন।
7. IDLE এলে playback শেষ করুন এবং interaction-level অস্থায়ী data পরিষ্কার করুন। তখনও pending call থাকলে lifecycle mismatch হিসেবে log করুন।

এই বিন্যাসে tool ধীর হলেও receiver সচল থাকে। ফলে intermediate audio, আরেকটি function call বা final response একই পথে আসতে পারে; একটি tool-এর latency পুরো session event loop বন্ধ করে না।

Interruption ও disconnect আলাদা terminal event

Extended Thinking session চলার সময় explicit role-সহ client content পাঠানো যায়, কিন্তু send_client_content-এ turn_complete=true দিলে সক্রিয় generation সঙ্গে সঙ্গে interrupt হয়। তাই microphone endpointing বা send action কখন completed turn পাঠাবে, তা client policy-তে স্পষ্ট রাখুন; ক্ষণিক voice activity যেন অনিচ্ছায় চলমান generation কেটে না দেয়।

ইচ্ছাকৃত interruption এলে পুরোনো playback থামানো যেতে পারে, কিন্তু running tool task-এর নীতি আলাদাভাবে নির্ধারণ করুন। Cancellation সম্ভব হলে task বাতিল করুন; তা সম্ভব না হলে generation ID বা interaction ID দিয়ে ফলটিকে stale হিসেবে চিহ্নিত করুন, যাতে পুরোনো ফল নতুন interaction-এর response হিসেবে না যায়। শুধু turnComplete দেখে pendingCalls মুছে ফেলা নিরাপদ নয়, কারণ ওই signal নিজে server-এর IDLE অবস্থা প্রমাণ করে না।

Socket disconnect আবার ভিন্ন ঘটনা: তখন pending ফল একই connection-এ পাঠানো সম্ভব নয়। Timeout, cancellation ও reconnect-এর নিয়ম application স্তরে রাখুন এবং পুরোনো session-এর call ID নতুন session-এ পুনর্ব্যবহার করবেন না।

Migration failure checklist

• turnComplete handler কি receive loop বন্ধ করে, listener সরায় বা UI-কে listening দেখায়? এসব কাজ interaction_status=IDLE branch-এ সরান।
• সব custom function declaration-এ behavior=NON_BLOCKING আছে কি? একটি blocking declaration-ও request-কে hard error-এ ফেলতে পারে।
• Tool executor কি receive callback-এর মধ্যে ফলের জন্য অপেক্ষা করে? করলে background task বা worker queue ব্যবহার করুন।
• প্রতিটি function response কি server-এর দেওয়া একই call ID বহন করে? শুধু function name দিয়ে concurrent call মেলাবেন না।
• IN_PROGRESS অবস্থায় turnComplete এলে pendingCalls অক্ষত থাকে কি? Reset হলে পরের tool response হারাতে পারেন।
• thinking_level কি low, medium বা high? Unsupported MINIMAL এবং scheduling field schema validation-এ আটকান।
• একটি message-এর সব audio part, tool call ও status process হচ্ছে কি? প্রথম অংশের পর return করলে বাকি content বাদ পড়তে পারে।
• Interruption, tool timeout, response-send failure ও socket disconnect কি আলাদা telemetry event? সবকিছুকে model completion হিসেবে log করলে প্রকৃত failure ধরা কঠিন হবে।

Migration-এর স্থায়ী invariant একটিই: utterance শেষ হওয়া playback-এর ঘটনা, interaction শেষ হওয়া server lifecycle-এর ঘটনা। প্রথমটির signal turnComplete; Extended Thinking-এ দ্বিতীয়টির নির্ভরযোগ্য signal interaction_status=IDLE।

আরও পড়ুন:

• Gemini Enterprise-এ খালি আসনের খরচ নেই: Google বদলাল AI বিলিং
• GitHub live migration এখন GA—repository চলবে, কিন্তু org settings যাবে না
• Gemini 3.8 Flash একই দামে বেশি ভাবছে—token খরচ কিন্তু বাড়তে পারে