ورک اسپیسز اور تنہائی

ورک اسپیس کیا ہے؟

ورک اسپیس Control Center میں سب سے اوپر کی سطح کا تنہائی ٹیننٹ ہے۔ یہ ایجنٹس، ریپوزٹریز، اسپیسز، ٹکٹس، میموری، پائپ لائنز اور اراکین کو ایک محدود سیاق میں سمو دیتا ہے۔ ورک اسپیس کے اندر ہونے والی ہر چیز اُسی کے اندر رہتی ہے۔

ایک عام ورک اسپیس کسی ایک پروجیکٹ یا ایک کوڈ بیس سے مطابقت رکھتا ہے۔ ہو سکتا ہے آپ کے ”api-service“، ”frontend-v2“ اور ”infrastructure“ کے لیے الگ الگ ورک اسپیسز ہوں۔

ورک اسپیس کے دائرے کا ڈیٹا

ورک اسپیس کی قطاریں اُسی ورک اسپیس کی اپنی SQLite فائل میں، <dataDir>/<workspaceId>/workspace.db پر رہتی ہیں۔ ہر ورک اسپیس کو ننگی فائل کے بجائے ایک ڈائریکٹری ملتی ہے، کیونکہ ورک اسپیس ایک ڈیٹا بیس سے زیادہ کچھ جمع کرتا ہے — فی گفتگو ورک ٹریز، ایجنٹ اور مہارت کی فائلیں، چیٹ بوٹ کی اسناد — اور اُسے ایک فولڈر دینے کا مطلب یہ ہے کہ یہ سب ایک ساتھ رہتا ہے اور ایک ساتھ حذف ہوتا ہے۔

شے	دائرہ
ایجنٹس	عین ایک ورک اسپیس سے تعلق رکھتے ہیں
ریپوزٹریز	ایک ورک اسپیس میں رجسٹر ہوتی ہیں (نیچے دیکھیں)
اسپیسز، گفتگوئیں اور پیغامات	ورک اسپیس کے دائرے میں
ٹکٹس، پروجیکٹس، پلانز، آرکیسٹریشنز	ورک اسپیس کے دائرے میں
میموری فیکٹس، پالیسیاں، ڈومینز، رسائی گرانٹس	ورک اسپیس کے دائرے میں
پائپ لائن رنز، ٹیمپلیٹس، ٹریگرز	ورک اسپیس کے دائرے میں
PR کی حالت، ریویو اسپیسز، ریویو کوہارٹس	ورک اسپیس کے دائرے میں
ایجنٹ رن لاگز اور ورکنگ میموری	ورک اسپیس کے دائرے میں
اراکین، دعوتیں، فی ریپو گرانٹس	ورک اسپیس کے دائرے میں
کوڈ گراف کے سمبلز اور ایجز	ورک اسپیس فائل کے اندر `repoId` سے محدود

اِن میں سے بیشتر قطاریں ایک workspaceId کالم رکھتی ہیں؛ تنہائی کو الگ ڈیٹا بیس فائلیں نافذ کرتی ہیں۔ نیچے تنہائی کا غیر متغیر اصول دیکھیں۔

ریپوز ورک اسپیس کے دائرے میں ہیں؛ ورک اسپیسز کے پار شناخت پاتھ سے ہوتی ہے

ایک ریپو کی قطار اُس کے ورک اسپیس کی اپنی ڈیٹا بیس فائل میں رہتی ہے — فائل ہی دائرہ ہے، اس لیے ٹیبل میں نہ کوئی workspaceId کالم ہے اور نہ کوئی جوائن ٹیبل۔

آپ کسی ورک اسپیس میں ریپو ترتیبات → ورک اسپیس → ریپوزٹریز سے شامل کرتے ہیں۔ ایک ہی چیک آؤٹ کو دو ورک اسپیسز میں رجسٹر کرنے سے دو مختلف ids والی دو آزاد قطاریں بنتی ہیں؛ ورک اسپیسز کے پار ریپو کی شناخت فائل سسٹم پاتھ (یا GitHub owner/name) سے ہوتی ہے، id سے کبھی نہیں۔

رجسٹریشن سخت ہے: پاتھ ایک git ورک ٹری کے اندر ہونا چاہیے، اُس میں ایک origin ریموٹ ہونا چاہیے اور وہ ریموٹ کسی معاون forge (github.com، gitlab.com یا bitbucket.org) کی طرف اشارہ کرنا چاہیے۔ forge ریموٹ سے پڑھا جاتا ہے اور ریپو پر محفوظ ہوتا ہے، اس لیے ایک ورک اسپیس تینوں کے ریپوز رکھ سکتا ہے۔ اس کے علاوہ ہر چیز مسترد کر دی جاتی ہے۔ جس فولڈر براؤزر سے آپ انتخاب کرتے ہیں وہ سرور ہوسٹ کا فائل سسٹم دکھاتا ہے، جو سرور کی --repo-roots اجازت فہرست تک محدود ہے (جس کا ڈیفالٹ سرور صارف کی ہوم ڈائریکٹری ہے)۔

کسی ریپو کو ورک اسپیس سے ہٹانا قطار کو یکسر حذف کر دیتا ہے اور اُس کے کوڈ سمبلز، ایجز، فائلیں، انڈیکس چیک پوائنٹس اور فی رکن گرانٹس کو سلسلہ وار حذف کرتا ہے۔ ڈسک پر موجود چیک آؤٹ کو کوئی فرق نہیں پڑتا۔

کوڈ گراف اُسی فائل میں، repoId کی کلید سے رہتا ہے، کیونکہ مختلف ورک اسپیسز میں وہی ریپوزٹری مختلف برانچوں پر اور مختلف کوڈ کے ساتھ ہو سکتی ہے۔

تنہائی کا غیر متغیر اصول

ورک اسپیسز کے پار ڈیٹا لیک کو بگ سمجھا جاتا ہے۔ تنہائی ساختی ہے اور کئی سطحوں پر نافذ کی جاتی ہے:

ڈیٹا بیس تہہ۔ ہر ورک اسپیس کی اپنی SQLite فائل ہوتی ہے، جو WorkspaceDatabaseManager.of(workspaceId) فراہم کرتا ہے۔ کوئی ورک اسپیس ڈیٹا بیس users، workspaces یا کسی دوسرے ورک اسپیس کے ٹیبلز کا اعلان نہیں کرتا، اس لیے ورک اسپیسز کے پار ریڈ کوئی ایسا بگ نہیں جو آپ لکھ سکیں — وہ کمپائل ہی نہیں ہوتا۔ ریپوزٹریز اپنا DAO ہر کال پر حل کرتی ہیں، ایک بار کیش کر کے نہیں رکھتیں، اور چونکہ ریپوزٹری کا ہر میتھڈ ایک لازمی workspaceId لیتا ہے، ورک اسپیس کا اندازہ لگایا جا سکتا نہ ڈیفالٹ کیا جا سکتا ہے۔
ورک اسپیس id ایک پاتھ سیگمنٹ ہے۔ چونکہ id ایک ڈائریکٹری نام بن جاتی ہے، اُسے ایک محفوظ واحد سیگمنٹ پیٹرن سے میل کھانا چاہیے (شروع میں حرف یا ہندسہ، پھر حروف، ہندسے، نقطے، انڈر اسکور، ہائفن؛ .. نہیں)۔ پروڈکٹ میں ہر جگہ ids UUIDs ہوتی ہیں۔ اس کے علاوہ ہر چیز صاف کیے جانے کے بجائے ایکسپشن پھینکتی ہے — یہی پاتھ ٹریورسل گارڈ ہے اور یہ زور سے ناکام ہوتا ہے بجائے اِس کے کہ کسی ورک اسپیس کا ڈیٹا کسی اور کے چنے ہوئے پاتھ پر لکھ دے۔
گہرائی میں دفاع۔ workspaceId کالم اب بھی موجود ہیں اور اب بھی لکھے جاتے ہیں۔ ایک فائل کے اندر زائد ہونے کے باوجود، وہ سنک فیڈ ٹریگرز، FTS انڈیکسز اور موجودہ قطار کی شکلیں بغیر تبدیلی کے رکھتے ہیں اور فائل کو اکیلا جانچے جانے پر خود وضاحتی بناتے ہیں — اسی پر ایکسپورٹ اور امپورٹ کا انحصار ہے۔
ڈومین تہہ۔ جو سروسز اکائیوں کو id سے بدلتی ہیں، آگے بڑھنے سے پہلے ایک ہی چوک پوائنٹ پر entity.workspaceId == workspaceId کی توثیق کرتی ہیں اور عدم مطابقت پر WorkspaceMismatchException پھینکتی ہیں — غلط سیاق سے آنے والی id کے لیے زوردار ناکامی۔ زور سے انکار کرنا اہم ہے: خاموش no-op بگ چھپا دیتا ہے اور آگے بڑھنا ڈیٹا لیک کرتا ہے۔
RPC تہہ۔ ریپو-RPC ڈسپیچر ہی چوک پوائنٹ ہے۔ ورک اسپیس کے دائرے کا ہر آپریشن لازماً اپنے دلائل میں workspace_id لے کر آتا ہے — لیک ہونے کوئی فی سیشن ”موجودہ ورک اسپیس“ نہیں ہے اور نامعلوم id کو، کسی چیز کے کوئی ڈیٹا بیس کھولنے سے پہلے، نہ ملا کے طور پر مسترد کر دیا جاتا ہے، اس لیے کوئی بری id بھوت workspace.db وجود میں نہیں لا سکتی۔ واقعی عالمی آپریشنز (نیوز فیڈ، فلیٹ قطار) اپنے آپ کو ایک واضح، نظرثانی شدہ فیصلے کے طور پر غیر محدود قرار دیتے ہیں۔ MCP ٹولز اسی اصول کی پیروی کرتے ہیں: ورک اسپیس کے دائرے کے ڈیٹا کو چھونے والا کوئی بھی ٹول workspace_id مانگتا ہے۔
ورک اسپیسز کے پار فین آؤٹ قابلِ شمار ہے۔ کئی ورک اسپیسز کے بارے میں سوال کا جواب دینے کا مطلب کئی ڈیٹا بیس کھولنا ہے۔ یہ فین آؤٹ ایک ہی ہیلپر، CrossWorkspaceQueries، تک محدود ہے، اس لیے وہ تمام چیزیں جو جائز طور پر اِس حد کو عبور کرتی ہیں، ڈاک کامنٹس کے پیچھے بکھرنے کے بجائے ایک ہی فائل کے کال سائٹس میں رہتی ہیں۔ وہ کال سائٹس یہ ہیں: سرور گیر مجموعی حساب، اسٹارٹ اپ ری کنسائلرز، ریٹینشن اور GC کی صفائیاں، بیک اپ، ایونٹ روٹرز — اور نیچے دی گئی رکنیت کی تلاش۔
صرف ID والی رسائی کافی نہیں۔ کسی اکائی کو اُس کی UUID سے تلاش کرنا ثابت نہیں کرتا کہ وہ کال کرنے والے کے ورک اسپیس سے تعلق رکھتی ہے۔ فائل کی تقسیم غلط فائل کو ناقابلِ رسائی بناتی ہے؛ ڈومین تہہ کی توثیق کوئی ایسی غلط id پکڑ لیتی ہے جو کسی جائز فائل کے ذریعے آئی ہو۔

رسائی دینے والی چیز رکنیت ہے، پیئرنگ کلید نہیں

ڈیوائس کی کوئی سند رکھنا ایک ڈیوائس کی توثیق کرتا ہے۔ یہ ورک اسپیس کے اندر کسی چیز کا اختیار نہیں دیتا۔ ورک اسپیس کے دائرے کا ہر آپریشن کال کرنے والے کا رکنیتی کردار حل کرتا ہے اور آپریشن کی قسم سے اخذ شدہ ایک کم از کم حد نافذ کرتا ہے — ریڈ کے لیے guest، تبدیلی کے لیے member، تباہ کن آپریشن کے لیے admin — اور ریپو کا مواد سامنے لانے والے آپریشنز کے لیے اضافی طور پر کال کرنے والے کی فی ریپو گرانٹ کی جانچ ہوتی ہے۔ رکنیت کے بغیر ایک درست پیئرنگ کلید کو Not a member of this workspace ملتا ہے۔

تنہائی کے لیے اِس کا نتیجہ صاف ہے: رکنیت کی قطاریں ورک اسپیس کی اپنی فائل میں رہتی ہیں، اس لیے ”اِس ورک اسپیس میں کون ہے؟“ ایک عام محدود ریڈ ہے۔ اُلٹا سوال — ”میں کن ورک اسپیسز میں ہوں؟“ — بذات خود فائلوں کے پار پھیلا ہوتا ہے، اس لیے یہ اُن چند منظور شدہ CrossWorkspaceQueries فین آؤٹس میں سے ایک ہے اور ورک اسپیس پکر، کوئی ورک اسپیس چنے جانے سے پہلے یہی چلاتا ہے۔

کرداروں کی سیڑھی اور ریپو گرانٹس کے لیے ملٹی پلیئر دیکھیں۔

عالمی رجسٹری

ہر چیز ورک اسپیس کے دائرے میں نہیں ہے۔ دوسرا ڈیٹا بیس، <dataDir>/global.db، وہ رکھتا ہے جو واقعی سرور گیر ہے:

ورک اسپیس رجسٹری، تاکہ سوئچر ایک بھی ورک اسپیس فائل کھولے بغیر ہر ورک اسپیس کی فہرست دے سکے — اور تاکہ کسی ورک اسپیس کا نام، لوگو، مالک، دستی ترتیب اور نرم حذف کا نشان اُس فائل سے باہر رہے جس کی وہ وضاحت کرتی ہے؛
شناخت: صارفین، صارف ترجیحات اور جوڑے ہوئے ڈیوائسز، کیونکہ ایک انسان ہر ورک اسپیس میں ایک ہی صارف ہے اور کوئی جوڑا ہوا ڈیوائس ورک اسپیس حذف ہونے پر بھی قائم رہتا ہے؛
فلیٹ قطار (ورکرز، جابز، پلیسمنٹ لاگ)، جس کا شیڈیولر ہر ٹک پر پوری قطار کو ہر ورکر سے ملاتا ہے؛
نیوز فیڈ، جو فی صارف ہے (فی ورک اسپیس نہیں) — کوئی فیڈ شامل کرنا آپ کے ساتھ ہر ورک اسپیس میں جاتا ہے؛
workspace_routes، وہ پری آتھ انڈیکس جو اُن داخلی مقامات کے لیے ”یہ کلید کس ورک اسپیس کی ہے؟“ کا جواب دیتا ہے جو صرف ایک سیکرٹ یا ایک مبہم id (دعوت کا ہیش، ویب ہک ٹوکن، ڈیپ لنک) لے کر آتے ہیں اور کوئی ورک اسپیس نہیں۔ وہاں چوک جانا نہ ملا ہونا ہے؛ جان بوجھ کر کوئی اسکین فال بیک نہیں ہے؛
انسٹال گیر ترتیبات اور شناخت: انسٹال id، ہوسٹ سطح کی ترتیبات، SSO کنکشنز اور منظم ایکشن پالیسیاں (ایک انسٹال گیر پابندی جو ورک اسپیس گارڈریلز کو صرف سخت تر کر سکتی ہے)۔

بوٹ صرف یہی فائل کھولتا ہے۔ ورک اسپیس فائلیں پہلی دسترس پر دیر سے کھلتی ہیں، اس لیے اسٹارٹ اپ کی لاگت اتنی ہی رہتی ہے چاہے ورک اسپیسز کتنی ہی تاریخ جمع کر لیں، اور فی فائل quick_check پہلے استعمال پر ادا ہوتا ہے، ریڈی بینر تک کے راستے پر نہیں۔

ایک ورک اسپیس فائل خود کی شناخت کے لیے صرف ایک قطار والا workspace_meta رکھتی ہے (اُس کی id، وہ انسٹال جس نے اُسے بنایا، وہ اسکیما ورژن جس کے ساتھ وہ بنی، اور کب)۔ ورک اسپیس کے بارے میں وضاحتی ہر چیز رجسٹری میں ہوتی ہے۔

ورک اسپیس بنانا

ورک اسپیس بنانا صرف رجسٹری میں قطار داخل کرنا نہیں ہے۔ ایک ہی آپریشن میں سرور بنانے والے صارف کو ownerUserId کے طور پر لکھتا ہے، اُس صارف کی مالک کردار والی رکنیت درج کرتا ہے اور ایک WorkspaceCreated ڈومین ایونٹ شائع کرتا ہے۔ اُس ایونٹ کے سننے والے پھر، ایڈمپوٹنٹ انداز میں اور پس منظر میں، یہ چیزیں سیڈ کرتے ہیں:

ایک CEO ایجنٹ اور چار ماہرین — qa، architect، engineer، librarian — جہاں ماہرین CEO کو رپورٹ کرتے ہیں؛
بلٹ اِن پائپ لائن ٹیمپلیٹس اور اُن کے ٹریگرز (ایونٹ اور دستی ٹریگرز فعال حالت میں آتے ہیں؛ شیڈیول شدہ ٹریگرز، روزانہ ورک ٹری-GC صفائی کے سوا، اختیاری ہیں)؛
اسٹارٹر ایوال سویٹس۔

یہ ہر ورک اسپیس کے لیے ہوتا ہے، صرف پہلے کے لیے نہیں۔ سیڈ کیے گئے ایجنٹس بغیر کسی اڈاپٹر کے بنائے جاتے ہیں، اس لیے وہ Anthropic کے ڈیفالٹ ماڈل کے ساتھ (claude-opus-4-8، جب تک آپ کوئی اور پن نہ کریں) Control Center (built-in) پر چلتے ہیں، یہاں تک کہ آپ ترتیبات → ورک اسپیس → ایجنٹس میں فی ایجنٹ اڈاپٹر اور ماڈل مقرر کریں۔ ایجنٹ ماڈل دیکھیں۔

مالک رکنیت کی یہ تحریر دکھنے سے زیادہ اہم ہے: اُس کے بغیر نئے بنائے گئے ورک اسپیس کا کوئی رکن نہ ہوتا اور بنانے والے کی اگلی ہر ورک اسپیس محدود کال مسترد ہو جاتی۔

حذف کرنا، ایکسپورٹ کرنا، امپورٹ کرنا

کسی ورک اسپیس کو حذف کرنا رجسٹری کی قطار کو نشان زد کرتا ہے اور ڈائریکٹری کا لنک کاٹ دیتا ہے۔ ورک اسپیس ہر فہرست اور تلاش سے غائب ہو جاتا ہے۔ رجسٹری کی قطار (نرم حذف شدہ) رہتی ہے تاکہ id بیک اپ اور مینٹیننس کو اب بھی معلوم رہے، مگر workspace.delete فوراً اُس ورک اسپیس کی ڈائریکٹری — ڈیٹا بیس، ورک ٹریز، ایجنٹ فائلیں اور باقی سب — WorkspaceDatabaseManager.dropAndClose کے ذریعے گرا دیتا ہے۔ صرف ورک اسپیس کا مالک ہی اُسے حذف کر سکتا ہے۔

چونکہ ایک ورک اسپیس ایک فائل ہے، ورک اسپیس کو آگے دینا ٹیبل بہ ٹیبل ڈمپ کے بجائے ایک فائل آپریشن ہے:

workspace.export ایک ہی VACUUM INTO ہے — سرور کے مسلسل خدمت کرتے رہتے ہوئے ایک ریڈ ٹرانزیکشن کے تحت لی گئی مستقل، ڈیفراگمنٹ شدہ اسنیپ شاٹ۔
workspace.import ایسی فائل کو اپناتا ہے اور ہدف ورک اسپیس کے پاس اس وقت جو کچھ موجود ہے اُسے بدل دیتا ہے۔ ایمبیڈڈ workspace_meta کسی امپورٹ کو ”اپنی ہی فائل، دوبارہ اپنائی گئی“ اور ”کسی دوسرے انسٹال کی فائل“ میں فرق کرنے دیتا ہے (دوسری کی اجازت ہے، مگر نظرانداز کرنے کے بجائے لاگ کی جاتی ہے)۔
server.backupNow پورے انسٹال کا اسنیپ شاٹ لائیو ڈیٹا ڈائر کو نقل کرنے والی ٹائم اسٹیمپ والی ڈائریکٹری میں لیتا ہے — manifest.json، global.db اور فی ورک اسپیس ایک <workspaceId>/workspace.db — چنانچہ بحالی صرف اُسے واپس کاپی کرنا ہے۔
server.listBackups اُس ڈائریکٹری کو تازہ ترین سے پہلے کی ترتیب میں واپس پڑھتا ہے، ہر اسنیپ شاٹ کے سائز اور ورک اسپیس فہرست کے ساتھ۔ جس اسنیپ شاٹ کا مینی فیسٹ غائب ہو یا جو ایسی فائلوں کے نام لے جو وہاں موجود نہ ہوں، وہ بھی رپورٹ ہوتا ہے، نامکمل کے طور پر نشان زد — اُسے چھپانا ہی وہ راستہ ہے جس سے کوئی آپریٹر یہ سمجھ بیٹھے کہ اُس کے پاس ایسا بیک اپ ہے جو دراصل نہیں ہے۔

بیک اپ آپریشنز ترتیبات → سرور → بیک اپ اور بحالی کے تحت رہتے ہیں: اب بیک اپ لیں انسٹال کا اسنیپ شاٹ لیتا ہے، فہرست دکھاتی ہے کہ کون سے اسنیپ شاٹس مکمل ہیں اور انسٹال کے مالک کو تصدیق کے بعد ایک حذف کرنے دیتی ہے، اور ہر ورک اسپیس ایکسپورٹ اور امپورٹ پیش کرتا ہے۔ بلٹ اِن Workspace backup پائپ لائن ہفتہ وار شیڈول پر صرف اُسی ورک اسپیس کا ڈیٹا بیس لیتی ہے اور اپنے اُن بیک اپس کو حذف کرتی ہے جو مقرر کردہ ریٹینشن عمر سے پرانے ہوں۔ کسی ورک اسپیس کو انسٹال اسنیپ شاٹ سے بحال کرنا workspace.import ہے جسے اسنیپ شاٹ کے <workspaceId>/workspace.db کی طرف اشارہ کیا گیا ہو؛ پورے انسٹال کی بحالی اب بھی اسنیپ شاٹ ڈائریکٹری کی، سرور بند حالت میں، واپس کاپی ہے۔

اِن میں سے کوئی بھی چیز ورک اسپیس ڈائریکٹری کا باقی حصہ نہیں لے کر چلتی۔ ورک اسپیس ایک ڈیٹا بیس سے زیادہ جمع کرتا ہے — چسپاں کی گئی تصاویر، مہارت اور ایجنٹ فائلیں، چیٹ اسناد، ورک ٹریز — اور ایکسپورٹ و امپورٹ فائل کو منتقل کرتے ہیں، اس لیے اُس کے ساتھ والی ہر چیز جہاں ہے وہیں رہتی ہے۔ اسناد کے لیے یہ جان بوجھ کر ہے اور ورک ٹریز کے لیے یہ ضائع ہونے والی چیز ہے؛ باقی کے لیے یہ جاننے کی ایک حد ہے، کوئی خصوصیت نہیں۔ بیک اپ حوالہ میں مکمل ٹیبل موجود ہے۔

سرور اور آپ کے ڈیوائس کے درمیان بیک اپ منتقل کرنا

اُوپر کا ہر آپریشن سرور کے پاتھوں کی زبان بولتا ہے، جو مکمل جواب صرف اُس وقت ہوتا ہے جب سرور آپ کی اپنی مشین ہو۔ تین دستخط شدہ HTTP روٹس — /backup/workspace، /backup/snapshot اور /backup/restore — باقی ہر ٹوپولوجی کے لیے بائٹس منتقل کرتے ہیں، اُسی مستند لین پر جو میڈیا پراکسی اور امیج اسٹور پہلے ہی استعمال کرتے ہیں۔ صفحے پر یہ ہر ایکسپورٹ اور ہر اسنیپ شاٹ کے ساتھ ایک ڈاؤن لوڈ بٹن ہے (کہاں اُترے گا یہ آپ چنتے ہیں)، اور اُس فائل سے بحالی کے لیے فائل منتخب کریں اور اپ لوڈ کریں ہے جو آپ کی زیرِ استعمال مشین پر رکھی ہو۔ اپ لوڈ وہی ہے جو اُس وقت کام کرتا ہے جب سرور آپ کی مشین نہ ہو: workspace.import چاہتا ہے کہ فائل پہلے سے ہوسٹ پر ہو، اور وہ وہاں اِسی طرح پہنچتی ہے۔

تین خصوصیات جاننے کے قابل ہیں:

ایک ڈاؤن لوڈ تازہ کاپی بناتا ہے اور سرور اُس میں سے کچھ نہیں رکھتا۔ ڈاؤن لوڈ کرنا ”ایکسپورٹ بٹن کی بنائی ہوئی فائل لے آؤ“ نہیں ہے — یہ دوبارہ ایکسپورٹ کرتا ہے، اُسے اسٹریم کرتا ہے اور اُسے حذف کر دیتا ہے۔ جواب اسی وجہ سے no-store کے ساتھ Accept-Ranges: none ہے: دوبارہ شروع ہونے والی رینج دو مختلف ایکسپورٹس کو ایک ایسی فائل میں جوڑ دیتی جو درست دکھتی ہے مگر ہے نہیں۔
اپ لوڈ ڈسک پر اسٹریم ہوتا ہے، کبھی بفر نہیں ہوتا، دونوں سروں پر، اور تیار کردہ کاپی ہر راستے سے باہر نکلتے وقت حذف ہو جاتی ہے — بشمول انکار کے۔ ورک اسپیس کا ڈیٹا بیس کوئی اسکرین شاٹ نہیں ہے۔
ریلے شدہ کنکشن کا کوئی HTTP اوریجن نہیں ہوتا، اس لیے وہاں ٹرانسفر کنٹرولز ایک ایسے نوٹ کے ساتھ غیر فعال ہوتے ہیں جو وجہ بتاتا ہے۔ سرور کی طرف کے پاتھوں کی زبان بولنے والی ہر چیز ریلے پر کام کرتی رہتی ہے؛ صرف بائٹ لینز کو براہِ راست کنکشن درکار ہے۔

متعدد ورک اسپیسز

آپ متعدد ورک اسپیسز ساتھ ساتھ چلا سکتے ہیں۔ ہر ایک آزادانہ کام کرتا ہے: ایک ورک اسپیس کے ایجنٹس کسی دوسرے ورک اسپیس کے ایجنٹس کو پیغام نہیں بھیج سکتے، کسی دوسرے ورک اسپیس کی میموری نہیں پڑھ سکتے اور اُس کے ٹکٹس نہیں دیکھ سکتے۔ ایجنٹ سے ایجنٹ پیغام رسانی میں وصول کنندہ کا تعین قطعی ہے اور کبھی کسی ورک اسپیس کو عبور نہیں کرتا۔

کوئی کراس ورک اسپیس ڈیش بورڈ نہیں ہے۔ /workspaces/:workspaceId/observability پر موجود اینالیٹکس سطح حالیہ رنز کی ایک محدود عالمی فیڈ کو سبسکرائب کرتی ہے اور فوراً اُسے فعال ورک اسپیس تک محدود کر دیتی ہے، اس لیے وہاں آپ کو ایک وقت میں ایک ہی ورک اسپیس نظر آتا ہے۔ کوئی شخص جِن واقعی کثیر ورک اسپیس سطحوں کو چھوتا ہے وہ ورک اسپیس پکر اور سوئچر ہی ہیں۔

ایک عملی حد جاننے کے قابل ہے: جس ورک اسپیس کو کوئی استعمال کر رہا ہو وہ کھلا رہتا ہے — کوئی LRU نہیں ہے۔ ایسے 32 سے زیادہ ہو جانے پر سرور انکار کے بجائے انتباہ کرتا ہے، کیونکہ ہر کھلی فائل ایک پس منظر isolate اور ایک پیج کیش رکھتی ہے۔ کراس ورک اسپیس فین آؤٹ فائلیں عارضی طور پر کھولتا ہے اور بعد میں، اگر کسی اور نے اُن پر دعویٰ نہ کیا ہو، بند کر دیتا ہے۔