Promise আর combinator — all, allSettled, race, any

১ · Promise কী — ভবিষ্যতের মানের রসিদ

পুরান ঢাকার একটি বিরিয়ানির দোকানে দুপুর একটায় ভিড়। আপনি টাকা দিলেন, কাউন্টার থেকে একটি টোকেন পেলেন — “৪৭ নম্বর”. বিরিয়ানি এখনো হাতে আসেনি, কিন্তু আপনার হাতে এমন একটি জিনিস আছে যা ভবিষ্যতের বিরিয়ানির প্রতিনিধি. টোকেন হাতে আপনি বসে থাকতে বাধ্য নন — পানি কিনতে পারেন, বন্ধুকে ফোন করতে পারেন। পরে দুটোর একটা ঘটবে: ডাক আসবে “৪৭ নম্বর, আপনার প্লেট রেডি”, অথবা “দুঃখিত, বিরিয়ানি শেষ — টাকা ফেরত নিন”. আর একবার যেটা ঘটল, সেটাই চূড়ান্ত। প্লেট হাতে দিয়ে পরে “আসলে শেষ হয়ে গেছে” বলা যায় না।

JavaScript-এর Promise ঠিক এই টোকেন। পর্ব ৩২-এ দেখেছেন, async কাজের ফল পেতে আমরা একটি callback function ভেতরে পাঠাতাম — “কাজ শেষে এটাকে ডাকবেন”. Promise ধারণাটা উল্টে দেয়: async function কোনো callback নেয় না, বরং সাথে সাথে একটি object ফেরত দেয়, যা বলে “ফল এখনো আসেনি, কিন্তু এলে এখানে পাবেন।” আপনি সেই object-এ নিজের handler জুড়ে দেন।

Callback থেকে promise — নিয়ন্ত্রণ কার হাতে

পার্থক্যটা শুধু লেখার ধরনে নয়, দায়িত্বে। Callback দিলে আপনি নিজের কোড অন্যের হাতে তুলে দেন — library ঠিক করে কবে, কতবার, কোন argument দিয়ে ডাকবে। ভুল library দুবার ডাকতে পারে, কখনো না-ও ডাকতে পারে, error-কে প্রথম argument-এ দিতে ভুলে যেতে পারে। একে বলে inversion of control. Promise-এ নিয়ন্ত্রণ ফেরত আসে আপনার কাছে, আর ভাষা নিজে কয়েকটি নিশ্চয়তা দেয়:

• একবারই settle: resolve দুবার ডাকলে, বা resolve-এর পরে reject ডাকলে, পরেরগুলো নিঃশব্দে উপেক্ষিত।
• দেরিতে জুড়লেও ফল পাবেন: promise শেষ হওয়ার এক ঘণ্টা পরে .then লাগালেও handler ঠিক সেই মান পায়। টোকেন হারিয়ে যায় না।
• যতজন খুশি শুনতে পারে: একই promise-এ পাঁচটি .then লাগালে পাঁচটিই চলবে, লাগানোর ক্রমে।
• Handler কখনো সাথে সাথে চলে না: সবসময় চলমান কোড শেষ হওয়ার পরে (অংশ ৫)। তাই আচরণ অনুমানযোগ্য।

তিন অবস্থা, আর দুটি গোলমেলে শব্দ

দুটি শব্দ প্রায়ই গুলিয়ে যায়। Settled মানে “আর pending নয়” — fulfilled বা rejected. আর resolved মানে “ভাগ্য ঠিক হয়ে গেছে” — এটা fulfilled-এর সমার্থক নয়. ধরুন আপনি একটি promise p-কে resolve করলেন আরেকটি promise slow দিয়ে: resolve(slow). এখন p resolved — তাকে আর অন্য কিছু দিয়ে resolve বা reject করা যাবে না — কিন্তু সে এখনো pending, কারণ সে slow-এর সাথে বাঁধা পড়েছে (lock in). slow সফল হলে p-ও সফল, slow ব্যর্থ হলে p-ও ব্যর্থ। অর্থাৎ “resolve” ডাকলেও promise rejected হতে পারে! Promise-এর নকশাকারীদের ব্যাখ্যায় (“States and Fates”) এই দ্বিতীয় দিকটির নাম “fate” — resolved বা unresolved.

নিচের ডায়াগ্রামে একটি promise-এর পুরো জীবন দেখুন — ১০০ ms পরে সফল হয়, আর ২০০ ms-এ ব্যর্থ করার চেষ্টাও আছে:

1const p = new Promise((resolve, reject) => {2  setTimeout(() => resolve("৳৫০০ জমা হলো"), 100);3  setTimeout(() => reject(new Error("দেরি")), 200);4});5const p2 = p.then((v) => console.log("পেলাম:", v));6console.log("অপেক্ষা করছি…");

২ · Promise তৈরি — executor, delay আর Promise.resolve

বেশিরভাগ সময় আপনি promise বানাবেন না, পাবেন — fetch (পর্ব ৩৫), Node.js-এর fs/promises, ডেটাবেস driver সবাই promise ফেরত দেয়। নিজে বানাতে হয় মূলত তখন, যখন পুরোনো callback-ধাঁচের কোনো API-কে promise-এ মুড়তে চান। তার যন্ত্র হলো constructor:

function delay(ms, value) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(value), ms);   // ms পরে value দিয়ে সফল
  });
}

delay(500, "চা রেডি").then((msg) => console.log(msg));   // আধা সেকেন্ড পরে: চা রেডি

new Promise-এ যে function দেন, তার নাম executor. সে দুটি function হাতে পায় — resolve আর reject. কাজ সফল হলে resolve(মান), ব্যর্থ হলে reject(new Error(…)). Executor-এর ভেতরে কোনো error ছোড়া হলে (throw) সেটিও স্বয়ংক্রিয়ভাবে rejection হয়ে যায়। কিন্তু একটি জিনিস প্রায় সবাইকে অবাক করে: executor সাথে সাথে, synchronous-ভাবে চলে — promise “পরে” কিছু করবে বলে executor-ও পরে চলবে, তা নয়। নিচে লেখা অক্ষরের ক্রম মিলিয়ে দেখুন:

1console.log("ক. অর্ডার নিলাম");2const p = new Promise((resolve) => {3  console.log("খ. executor সাথে সাথে চলে");4  resolve("ঙ. then — সবার শেষে");5  console.log("গ. resolve-এর পরেও কোড চলে");6});7p.then((msg) => console.log(msg));8console.log("ঘ. শেষ লাইন");

Promise.resolve, Promise.reject আর thenable

যদি মান হাতেই থাকে, কিন্তু কোনো API promise চায়? Promise.resolve(42) সাথে সাথে fulfilled একটি promise দেয়, Promise.reject(new Error("না")) দেয় rejected promise. একটি কাজের নিয়ম: Promise.resolve(x)-এ x যদি আগে থেকেই একটি native promise হয়, নতুন কিছু বানায় না — সেটাকেই ফেরত দেয়। তাই “মান হোক বা promise, আমি promise চাই” — এমন জায়গায় Promise.resolve(x) নিরাপদ মোড়ক।

আর যদি x এমন কোনো object হয় যার একটি then method আছে? JavaScript তখন সেটাকে promise-এর মতো ধরে নেয় — একে বলে thenable. Promise.resolve({ then(ok) { ok("৪২"); } }) fulfilled হয় "৪২" দিয়ে। এই নিয়মের জন্যই jQuery, Bluebird বা পুরোনো কোনো library-র promise আর native promise একই শিকলে মেশানো যায় (ভাবনার প্রশ্ন ২)। উল্টো দিকটা হলো, ভুল করে কোনো সাধারণ object-এ then নামের property রাখলে, সেটি promise থেকে return করলে অদ্ভুত আচরণ পাবেন — শিকল সেই then ডেকে বসে থাকবে।

৩ · ফল নেওয়া — then, catch আর finally

Promise-এর ফল নেওয়ার তিনটি method — প্রত্যেকটি একটি নতুন promise ফেরত দেয়:

finally-এর “এগিয়ে দেওয়া” আচরণটি গুরুত্বপূর্ণ: Promise.resolve(5).finally(() => 99).then(console.log) ছাপে 5, 99 নয়। এটা পর্ব ২৯-এর finally block-এর মতোই — পরিষ্কারের কাজের জায়গা (লোডিং চিহ্ন সরানো, বাটন আবার চালু), ফল বদলানোর নয়।

৪ · Chaining-এর নিয়ম — return, throw আর error-এর পথ

Promise-এর আসল শক্তি chaining-এ। যেহেতু প্রতিটি .then নতুন promise দেয়, আপনি লিখতে পারেন a().then(b).then(c).then(d) — পর্ব ৩২-এর ডানদিকে সরে যাওয়া callback-এর পিরামিডের বদলে একটি সোজা লাইন। নতুন promise-টি কী নিয়ে শেষ হবে, তা ঠিক হয় handler কী করল তা দেখে:

চতুর্থটি নিয়ে আরেকটু। Arrow function-এ { } দিলে implicit return থাকে না (পর্ব ১৩) — (id) => reserve(id) মান ফেরত দেয়, কিন্তু (id) => { reserve(id); } দেয় না। ফল দুই রকম ক্ষতি: পরের ধাপ ভুল মান (undefined) পায় আর reserve শেষ হওয়ার আগেই চলে যায়; আর reserve ব্যর্থ হলে তার rejection এই শিকলের বাইরে একা পড়ে থাকে — unhandled. কোনো error message দেখায় না যে “return নেই” — তাই এটা খুঁজে পাওয়া কঠিন। নিয়ম মুখস্থ রাখুন: then-এর ভেতরে async কিছু শুরু করলে সেটা return করুন।

Error কোন পথে নামে, আর কীভাবে সামলে ওঠে

পর্ব ২৯-এ দেখেছেন, synchronous কোডে throw হলে error call stack বেয়ে প্রথম try/catch পর্যন্ত ওঠে। Promise শিকলে তার প্রতিরূপ: rejection শিকল বেয়ে নিচে নামে, যতক্ষণ না প্রথম onRejected handler (সাধারণত .catch) পায়। মাঝের সব then(onFulfilled) বাদ পড়ে। আর catch যদি একটি মান return করে, শিকল আবার fulfilled পথে ফিরে আসে:

1Promise.resolve(2)2  .then((n) => n * 10)3  .then((n) => { throw new Error("সীমা পার: " + n); })4  .then((n) => console.log("চলবে না", n))5  .catch((e) => { console.log("ধরা:", e.message); return 0; })6  .then((n) => console.log("আবার চালু:", n))7  .finally(() => console.log("শেষ"));

বাস্তব শিকল — অর্ডার দেওয়া

একটি অনলাইন দোকানে অর্ডারের চারটি ধাপ: স্টক যাচাই → মাল সংরক্ষণ (reserve) → টাকা কাটা → SMS পাঠানো। প্রতিটি ধাপ async, আর যেকোনো ধাপ ব্যর্থ হতে পারে। Callback দিয়ে এটা চার স্তর গভীর পিরামিড, প্রতিটি স্তরে আলাদা error-পরীক্ষা। Promise দিয়ে একটি লাইন আর একটি catch. নেটওয়ার্কের বদলে এখানে setTimeout-ভিত্তিক নকল async function:

const delay = (ms, value) => new Promise((resolve) => setTimeout(resolve, ms, value));
const stock = { "ফ্যান": 0, "কেটলি": 4 };

function checkStock(item) {
  return delay(50).then(() => {
    if (!stock[item]) throw new Error(`${item} স্টকে নেই`);
    return item;
  });
}
const reserve = (item) => delay(50, `${item} রিজার্ভ`);
const charge = (r) => delay(50, `${r}, ৳১২০০ কাটা হলো`);
const sendSms = (msg) => { console.log("SMS:", msg); return "অর্ডার সম্পন্ন"; };

function placeOrder(item) {
  console.log("অর্ডার শুরু:", item);
  return checkStock(item).then(reserve).then(charge).then(sendSms)
    .catch((err) => `ব্যর্থ: ${err.message}`)
    .finally(() => console.log("লোডিং চিহ্ন সরানো"));
}
placeOrder("কেটলি")
  .then((r) => { console.log(r); return placeOrder("ফ্যান"); })
  .then((r) => console.log(r));
console.log("এই লাইন আগে — কেউ অপেক্ষায় বসে নেই");

৫ · Handler সবসময় পরে চলে — microtask আর unhandled rejection

Promise-এর handler কখনো “এখনই” চলে না — promise আগে থেকেই fulfilled হলেও না। মানদণ্ড বলে, handler একটি job হিসেবে লাইনে দাঁড়াবে; ব্রাউজার আর Node.js সেটাকে microtask queue-তে রাখে। পর্ব ৩১-এর নিয়মটা মনে করুন: বর্তমান কোড শেষ হলেই সব microtask চলে — পরের timer বা click-এর মতো task-এর আগে. তাই নিচের কোডে ক্রম হয় ১, ৩, ২:

setTimeout(() => console.log("২. timer (task)"), 0);
Promise.resolve().then(() => console.log("৩? না — এটা আগে: microtask"));
console.log("১. synchronous");
// প্রত্যাশিত আউটপুট:
// ১. synchronous
// ৩? না — এটা আগে: microtask
// ২. timer (task)

কেন এই নিয়ম? কারণ “কখনো সাথে সাথে, কখনো পরে” চলা API সবচেয়ে বিপজ্জনক — একই কোড ক্যাশে ডেটা থাকলে এক ক্রমে, না থাকলে আরেক ক্রমে চলে, আর বাগ শুধু মাঝে মাঝে দেখা দেয়। Node.js-জগতে একে বলা হয় “releasing Zalgo”. Promise এই অনিশ্চয়তা পুরোপুরি মুছে দেয়: handler সবসময় async. উল্টো দিকে একটি সতর্কতা: microtask-এর ভেতরে অবিরাম নতুন microtask বানালে (যেমন নিজেকে বারবার ডাকা then) event loop কখনো timer বা রেন্ডারিং-এ পৌঁছায় না — পাতা জমে যায়।

কেউ না ধরা rejection

Synchronous error কেউ না ধরলে uncaught হয় (পর্ব ২৯)। Promise-এর ক্ষেত্রে সমস্যাটা সূক্ষ্ম: rejected promise-এ হয়তো পরে কেউ .catch লাগাবে — engine কীভাবে জানবে? তাই নিয়ম হলো: একটি promise rejected হলো, আর microtask লাইন খালি হওয়া পর্যন্ত তাতে কোনো handler লাগল না — তখন সেটা unhandled rejection.

• ব্রাউজারে: console-এ লাল লেখা Uncaught (in promise) Error: …, আর window-এ unhandledrejection event. পাতা চলতে থাকে, কিন্তু কাজটি নিঃশব্দে ব্যর্থ। পরে কেউ handler লাগালে rejectionhandled event আসে। পর্ব ২৯-এর global handler এই event-টিই শোনে — রিপোর্ট করার জন্য।
• Node.js-এ: Node.js 15 থেকে ডিফল্ট মোড --unhandled-rejections=throw: rejection-টি uncaught exception হিসেবে ছোড়া হয়, আর কোনো process.on("unhandledRejection") বা uncaughtException handler না থাকলে পুরো process বন্ধ হয়ে যায় (exit code 1). এর আগে Node শুধু একটি সতর্কবার্তা ছাপত — অনেক সার্ভার বছরের পর বছর লুকানো ব্যর্থতা নিয়ে চলত।

৬ · Combinator — all, allSettled, race, any

এ পর্যন্ত একটির পর একটি কাজ দেখেছি। কিন্তু প্রায়ই কয়েকটি কাজ একসাথে চালাতে চান, তারপর একটি সিদ্ধান্ত নিতে চান। এর জন্য চারটি combinator — প্রত্যেকটি একগুচ্ছ promise (আসলে যেকোনো iterable) নিয়ে একটি নতুন promise দেয়। পার্থক্য শুধু দুটি প্রশ্নে: কখন শেষ হবে, আর কী ফল দেবে।

একই তিনটি promise চারটি combinator-কে দিলে কী হয়, সময় ধরে দেখুন। A দ্রুত কিন্তু ব্যর্থ (৫০ ms), B ধীর আর সফল (১৫০ ms), C মাঝারি আর সফল (১০০ ms). ধরুন wait(ms, মান, ব্যর্থ?) একটি নকল async function:

1const A = wait(50, "A বন্ধ", true);  // ৫০ ms-এ ব্যর্থ2const B = wait(150, "B");           // ১৫০ ms-এ সফল3const C = wait(100, "C");           // ১০০ ms-এ সফল4Promise.all([A, B, C]);5Promise.allSettled([A, B, C]);6Promise.race([A, B, C]);7Promise.any([A, B, C]);

এবার নিজে চালিয়ে দেখুন — প্রতিটি combinator পায় তিনটি নতুন promise (একই সময়সূচি), আর শেষে একটি any যার সবগুলোই ব্যর্থ:

const wait = (ms, v, fail = false) => new Promise((ok, no) =>
  setTimeout(() => (fail ? no(new Error(v)) : ok(v)), ms));
const three = () => [
  wait(50, "A বন্ধ", true),   // দ্রুত, কিন্তু ব্যর্থ
  wait(150, "B"),             // ধীর, সফল
  wait(100, "C"),             // মাঝারি, সফল
];
const show = (name) => [
  (v) => console.log(name, "→ সফল:", v),
  (e) => console.log(name, "→ ব্যর্থ:", e.message),
];
Promise.all(three()).then(...show("all"));
Promise.race(three()).then(...show("race"));
Promise.any(three()).then(...show("any"));
Promise.allSettled(three()).then((results) =>
  console.log("allSettled →", results.map((r) =>
    r.status === "fulfilled" ? r.value : `ব্যর্থ (${r.reason.message})`)));
Promise.any([wait(60, "x", true), wait(70, "y", true)])
  .catch((e) => console.log(e.name, e.message, e.errors.map((x) => x.message)));

কোন কাজে কোনটি — চারটি বাস্তব দৃশ্য

পণ্যের পাতা — Promise.all. একটি পণ্যের পাতায় লাগে পণ্যের তথ্য, রিভিউ আর ডেলিভারির আনুমানিক সময়। তিনটি একে অপরের ওপর নির্ভর করে না — তাই একসাথে চান:

Promise.all([getProduct(id), getReviews(id), getDeliveryEstimate(id, "সিলেট")])
  .then(([product, reviews, eta]) => render(product, reviews, eta))   // ক্রম নিশ্চিত
  .catch((err) => showError("পাতা লোড হয়নি", err));

তিনটি কাজের প্রতিটি ৩০০ ms নিলে মোট সময় প্রায় ৩০০ ms, একটির পর একটি করলে ৯০০ ms. Array destructuring (পর্ব ১৭) দিয়ে ফল নেওয়া যায় কারণ ক্রম তালিকার, শেষ হওয়ার নয়। কিন্তু ভাবুন: রিভিউ সার্ভার পড়ে গেলে পুরো পাতাই “লোড হয়নি”? এখানেই পরের combinator.

Dashboard — Promise.allSettled. একটি দোকানের মালিকের dashboard-এ ছয়টি widget: আজকের বিক্রি, স্টক, অর্ডার, bKash লেনদেন, রিভিউ, আবহাওয়া। আবহাওয়ার API বন্ধ বলে বাকি পাঁচটি দেখাবে না — এটা অগ্রহণযোগ্য। allSettled সবার ফল দেয়, প্রত্যেকে নিজের status নিয়ে: যেগুলো "fulfilled" সেগুলো দেখান, "rejected"-গুলোর জায়গায় “এই তথ্য এখন পাওয়া যাচ্ছে না” লিখুন। প্রশ্নটা হলো — একটির ব্যর্থতায় কি পুরো কাজ অর্থহীন? হ্যাঁ হলে all (যেমন অর্ডারের সব আইটেমের দাম না পেলে মোট দাম দেখানো যায় না), না হলে allSettled.

Request timeout — Promise.race. কোনো সার্ভার উত্তর না দিলে promise চিরকাল pending থাকতে পারে। race দিয়ে একটি সময়সীমা বসান:

function withTimeout(promise, ms) {
  let timer;
  const timeout = new Promise((_, reject) => {
    timer = setTimeout(() => reject(new Error(`${ms} ms পার, উত্তর আসেনি`)), ms);
  });
  return Promise.race([promise, timeout]).finally(() => clearTimeout(timer));
}

withTimeout(getBalance("01711…"), 3000).then(show).catch(showRetryButton);

finally-তে clearTimeout জরুরি — নইলে কাজ সফল হলেও timer বেঁচে থাকে, আর Node.js-এ process অকারণে খোলা থাকে। আর মনে রাখুন: timeout হলেও আসল কাজটি থামেনি, সার্ভারে request চলছেই — শুধু আপনি ফলটা উপেক্ষা করছেন। সত্যিকারের বাতিল আর AbortSignal.timeout() পর্ব ৩৬-এ।

সবচেয়ে দ্রুত mirror — Promise.any. একটি বড় ফাইল তিনটি সার্ভারে আছে — ঢাকা, সিঙ্গাপুর, ফ্রাঙ্কফুর্ট। যেটা আগে উত্তর দেয় সেটাই চাই, কোনোটা বন্ধ থাকলে কিছু যায় আসে না: Promise.any([ping(dhaka), ping(sg), ping(fra)]). এখানে race ভুল হতো — ঢাকার সার্ভার ১০ ms-এ “connection refused” দিলে race সেটাকেই ফল ধরে ব্যর্থ হতো, যদিও সিঙ্গাপুর ৮০ ms-এ ঠিকই দিত। আর সবগুলো ব্যর্থ হলে err.errors-এ তিনটি কারণই পাবেন — log-এর জন্য দারুণ।

Promise.withResolvers — executor-এর বাইরে থেকে শেষ করা

কখনো promise তৈরি হয় এক জায়গায়, আর শেষ হয় সম্পূর্ণ অন্য জায়গায় — যেমন “ব্যবহারকারী নিশ্চিত করুন” dialog: promise দেওয়া হলো এখন, resolve হবে বাটনে ক্লিক হলে। আগে এর জন্য লেখা হতো let resolve; const p = new Promise((r) => { resolve = r; });. ES2024-এ এসেছে Promise.withResolvers(), যা একসাথে { promise, resolve, reject } দেয়:

function askConfirm(dialog) {
  const { promise, resolve } = Promise.withResolvers();
  dialog.querySelector(".yes").addEventListener("click", () => resolve(true), { once: true });
  dialog.querySelector(".no").addEventListener("click", () => resolve(false), { once: true });
  dialog.showModal();
  return promise;
}
askConfirm(deleteDialog).then((ok) => ok && deleteOrder(id));

Edge আর Chrome 119 থেকে, Firefox 121 থেকে, Safari 17.4 থেকে এটি আছে; Node.js-এ 22 থেকে — তাই Node.js 20-এ চালাতে হলে পুরোনো let resolve কৌশলই লাগবে।

৭ · Callback থেকে promise, একসাথে বনাম পরপর, আর চেনা anti-pattern

Callback-কে promise-এ মোড়ানো

পর্ব ৩২-এর Node.js-ধাঁচের callback — শেষ argument-এ (err, value) — promise-এ রূপান্তর করার কাজকে বলে promisify. হাতে করা যায়, আবার Node.js-এ তৈরি যন্ত্রও আছে:

const fs = require("node:fs");
const { promisify } = require("node:util");

// হাতে মোড়ানো: callback-এর দুই পথ → resolve/reject
function readFileP(path) {
  return new Promise((resolve, reject) => {
    fs.readFile(path, "utf8", (err, text) => (err ? reject(err) : resolve(text)));
  });
}

// util.promisify একই কাজ করে দেয়
const readFile2 = promisify(fs.readFile);

fs.writeFileSync("order.txt", "কেটলি × ১");
readFileP("order.txt").then((t) => console.log("পেলাম:", t));
readFile2("nai.txt", "utf8").catch((e) => console.log("ব্যর্থ:", e.code));
// প্রত্যাশিত আউটপুট (ক্রম ফাইল সিস্টেমের ওপর নির্ভর করতে পারে):
// পেলাম: কেটলি × ১
// ব্যর্থ: ENOENT

বাস্তবে আজ এটা খুব কম লাগে — Node.js-এর বেশিরভাগ API-র promise-সংস্করণ আছে (require("node:fs/promises"), timers/promises-এর setTimeout). তবে পুরোনো library-তে আটকে গেলে এই কৌশলই ভরসা। এখানে new Promise ব্যবহার করা ঠিক, কারণ ভেতরে কোনো promise নেই — শুধু callback.

পরপর বনাম একসাথে

দশটি invoice লোড করবেন। দুটি পথ:

const ids = [11, 12, 13];

// পরপর: একটি শেষ হলে পরেরটি শুরু (মোট ≈ ৩ × এক কাজের সময়)
const sequential = ids.reduce(
  (chain, id) => chain.then((list) => loadInvoice(id).then((inv) => [...list, inv])),
  Promise.resolve([])
);

// একসাথে: সব একবারে শুরু (মোট ≈ সবচেয়ে ধীর কাজটির সময়)
const parallel = Promise.all(ids.map(loadInvoice));

reduce দিয়ে শিকল (পর্ব ১৬): শুরু একটি খালি array-র promise দিয়ে, আর প্রতিটি id শিকলে একটি করে ধাপ যোগ করে। পরপর তখনই দরকার যখন একটি ধাপ আগেরটির ফলের ওপর নির্ভর করে, অথবা ক্রম জরুরি (ব্যাংকে একটির পর একটি লেনদেন)। বাকি সব ক্ষেত্রে একসাথে অনেক দ্রুত। পরের পর্বের async/await-এ পরপর-এর কোডটা একটি সাধারণ for…of লুপ হয়ে যাবে — অনেক বেশি পড়ার মতো।

তবে “সব একসাথে” সীমাহীন নয়। ৫,০০০টি ছবি আপলোড করতে Promise.all(photos.map(upload)) লিখলে ৫,০০০টি request একসাথে ছুটবে — ব্রাউজার আটকে যাবে, সার্ভার rate limit-এ আপনাকে আটকাবে। দরকার concurrency limit: একসাথে সর্বোচ্চ ৪টি, একটি শেষ হলে পরেরটি। এর নকশা পর্ব ৩৬-এ।

চারটি চেনা anti-pattern

// ✗ ১. nested then — callback hell ফিরে এলো, আর return নেই
getUser(id).then((user) => {
  getOrders(user).then((orders) => show(orders));   // এর error কে ধরবে?
});
// ✓ চ্যাপ্টা শিকল, শেষে একটি catch
getUser(id).then(getOrders).then(show).catch(report);

// ✗ ২. explicit construction — আগেই থাকা promise-কে আবার new Promise-এ মোড়ানো
function getPrice(id) {
  return new Promise((resolve, reject) => {
    fetchProduct(id).then((p) => resolve(p.price));   // reject-এর পথ ভুলে গেছে!
  });
}
// ✓ promise তো আছেই — শুধু রূপান্তর করে return
const getPrice2 = (id) => fetchProduct(id).then((p) => p.price);

1. Nested then: then-এর ভেতরে then লিখলে পর্ব ৩২-এর পিরামিড ফিরে আসে। ভেতরের promise return না করলে বাইরের শিকল তার জন্য অপেক্ষা করে না, আর ভেতরের ব্যর্থতা বাইরের catch-এ পৌঁছায় না। ব্যতিক্রম শুধু তখন, যখন ভেতরে আগের ধাপের দুটি মান একসাথে লাগে — সেটাও async/await-এ (পর্ব ৩৪) সহজে মেটে।
2. Explicit construction anti-pattern: উপরের getPrice-এ fetchProduct ব্যর্থ হলে বাইরের promise চিরকাল pending — কোনো error নেই, কোনো উত্তর নেই, শুধু ঘুরতে থাকা লোডিং চিহ্ন। নিয়ম: new Promise শুধু callback বা event-ভিত্তিক API মোড়াতে।
3. catch ভুলে যাওয়া: শিকলের শেষে catch নেই মানে প্রতিটি ব্যর্থতা unhandled rejection — ব্রাউজারে নীরব ব্যর্থতা, Node.js-এ ক্র্যাশ। যে function শিকল return করে, তার ডাকার জায়গায় catch থাকলেই যথেষ্ট; মাঝের প্রতিটি function-এ catch লাগবে না।
4. Callback আর promise মেশানো: একই function-এ callback নেওয়া আর promise ফেরত দেওয়া, বা then-এর ভেতরে callback-ধাঁচের API ডেকে ফল বাইরের variable-এ রাখা। এতে দুই জগতের error-পথ আলাদা হয়ে যায় — একটি পথ সবসময় বাদ পড়ে। আগে মুড়ে নিন (promisify), তারপর পুরোটা promise-এ।

ইন্টারভিউর একটি চিরচেনা প্রশ্ন: “Promise.all নিজে লিখুন।” মূল কৌশল তিনটি — ফল রাখুন সূচক ধরে (শেষ হওয়ার ক্রমে নয়), কয়টি বাকি তা গুনুন, আর প্রথম ব্যর্থতায় reject:

function myAll(items) {
  return new Promise((resolve, reject) => {
    const results = [];
    let left = items.length;
    if (left === 0) return resolve(results);       // খালি তালিকা → সাথে সাথে []
    items.forEach((item, i) => {
      Promise.resolve(item).then((value) => {        // সাধারণ মানও চলবে
        results[i] = value;                          // ক্রম ঠিক রাখে সূচক
        if (--left === 0) resolve(results);
      }, reject);                                    // প্রথম ব্যর্থতাই জেতে
    });
  });
}

৮ · AI-এর যুগে — promise-কোডে AI-এর চেনা ভুল

AI promise-কোড খুব দ্রুত লেখে, আর প্রায়ই সেটা চলেও — কারণ পরীক্ষার সময় নেটওয়ার্ক ভালো, সার্ভার চালু। Promise-এর বাগ দেখা দেয় ব্যর্থতার পথে: একটি সার্ভার ধীর, একটি request ব্যর্থ, দুটি কাজের ক্রম উল্টে গেল। তাই AI-এর লেখা কোড পড়ার সময় “সব ঠিক থাকলে” নয়, “একটি ধাপ ব্যর্থ হলে কী হয়” — এই প্রশ্ন নিয়ে পড়ুন।

AI-এর লেখা promise-কোড — যাচাইয়ের চেকলিস্ট

• প্রতিটি then-এর ভেতরে শুরু হওয়া async কাজ return করা হয়েছে; { }-সহ arrow function-এ return চোখে পড়ছে
• কোনো then-এর ভেতরে আরেকটি then-এর পিরামিড নেই; শিকল চ্যাপ্টা
• new Promise শুধু callback/event-ভিত্তিক API মোড়াতে; সেখানে reject-এর পথও আছে
• combinator ঠিক বাছাই: “একটির ব্যর্থতায় সব অর্থহীন?” হ্যাঁ → all, না → allSettled; “প্রথম সফল” → any; timeout → race
• প্রতিটি শিকলের শেষে একটি অর্থপূর্ণ catch আছে; খালি .catch(() => {}) নেই
• স্বাধীন কাজ একসাথে চলছে, কিন্তু শত শত কাজ হলে concurrency সীমা আছে
• নিজে একটি ধাপ ব্যর্থ করে আর একটি ধাপ ধীর করে চালিয়ে দেখেছি; console-এ Uncaught (in promise) আসেনি