प्रॉम्प्ट और स्कोप
2 GB CSV, 20 MB मेन-थ्रेड मेमोरी बजट, और प्रत्येक स्वीकृत (acknowledged) चंक के बाद 100 ms के भीतर प्रोग्रेस अपडेट मानकर चलें। उपयोगकर्ता रीलोड कर सकता है या 30 मिनट के लिए ऑफ़लाइन हो सकता है। क्लाइंट को पूरी फ़ाइल को दोबारा पढ़े बिना रीज़्यूमे करना होगा, इंटरफ़ेस को रिस्पॉन्सिव रखना होगा, और सर्वर द्वारा स्वीकार किए जाने से पहले कभी भी चंक के अपलोड होने का दावा नहीं करना होगा। OPFS पेज ऑरिजिन के लिए प्राइवेट है; यह उपयोगकर्ता को दिखाई देने वाले फ़ोल्डर हैंडल से अलग है।
इंटरव्यूअर क्या जांच रहा है
- फ़ाइल आकार, पर्सिस्टेंस, परमिशन और ब्राउज़र सपोर्ट के आधार पर स्टोरेज प्रिमिटिव चुनना।
- UI स्टेट को असंगत किए बिना पार्सिंग और बाइट I/O को मेन थ्रेड से हटाना।
- चंक आइडेंटिटी, चेकसम, रीट्राई और सर्वर रिकॉन्सिलेशन के साथ एक रीज़्यूमेबल प्रोटोकॉल को परिभाषित करना।
- कोटा प्रेशर, एविक्शन (eviction), कैंसिलेशन, प्राइवेसी और असमर्थित (unsupported) ब्राउज़रों को संभालना।
पूछने के लिए स्पष्टीकरण संबंधी प्रश्न
पूछें कि क्या रीलोड के बाद मूल फ़ाइल उपलब्ध रहनी चाहिए, क्या सर्वर आउट-ऑफ-ऑर्डर चंक्स स्वीकार करता है, क्या पंक्तियों (rows) को क्रमिक रूप से पार्स किया जा सकता है, और कौन से ब्राउज़र दायरे में हैं। यदि सर्वर उपयोगकर्ता द्वारा चुनी गई फ़ाइल से सीधे स्ट्रीम कर सकता है, तो स्थानीय पर्सिस्टेंस अनावश्यक हो सकता है; यदि रीलोड रिकवरी अनिवार्य है, तो OPFS या कोई अन्य ड्यूरेबल स्टोर डिज़ाइन का हिस्सा बन जाता है।
30 सेकंड का उत्तर
मैं OPFS में upload_id, सोर्स फ़िंगरप्रिंट, चंक साइज़, स्वीकृत रेंज और चेकसम स्थिति के साथ एक छोटा मैनिफ़ेस्ट रखूँगा। एक डेडिकेटेड वर्कर सीमित स्लाइस पढ़ता है, उसे पेंडिंग चिह्नित करने से पहले एक ड्यूरेबल चंक लिखता है, और एक इडेम्पोटेंट चंक कुंजी के साथ अपलोड करता है। सर्वर स्वीकृत रेंज की रिपोर्ट करता है, इसलिए रीट्राई अनुमान लगाने के बजाय रिकॉन्साइल करता है। मेन थ्रेड को थ्रॉटल किए गए प्रोग्रेस संदेश प्राप्त होते हैं और वह कैंसिलेशन और एक्सेसिबल स्टेटस के लिए ज़िम्मेदार रहता है। फ़ीचर डिटेक्शन, स्टोरेज-कोटा हैंडलिंग, और यूज़र-सिलेक्टेड-फ़ाइल फ़ॉलबैक असमर्थित या एविक्टेड क्लाइंट्स की सुरक्षा करते हैं।
चरण-दर-चरण गहन विश्लेषण
1. स्टोरेज और सीमाएं (boundaries) चुनें
मैनिफ़ेस्ट और छोटे मेटाडेटा को एक ड्यूरेबल ब्राउज़र स्टोर में रखें, और बड़े अस्थायी चंक्स को OPFS में रखें। OPFS ऑरिजिन-प्राइवेट है और एक्सेस के लिए परमिशन प्रॉम्प्ट की आवश्यकता नहीं होती है; उपयोगकर्ता-दृश्यमान फ़ाइल हैंडल एक अलग परमिशन मॉडल का पालन करते हैं और उनके लिए एक स्पष्ट जेस्चर की आवश्यकता होती है। सिंक्रोनस एक्सेस हैंडल या अन्य ब्लॉकिंग कार्य के लिए एक वर्कर का उपयोग करें ताकि मेन थ्रेड कभी भी डिस्क I/O की प्रतीक्षा न करे।
2. रीज़्यूम को एक प्रोटोकॉल बनाएं, न कि केवल एक प्रोग्रेस बार
एक uploadid और डिटर्मिनिस्टिक चंक नंबर जनरेट करें। प्रत्येक अनुरोध uploadid, चंक इंडेक्स, बाइट रेंज, लंबाई और चेकसम ले जाता है। सर्वर स्वीकृत रेंज को स्टोर करता है और स्टेटस पर उन्हें लौटाता है। समान चंक आइडेंटिटी के साथ रीट्राई इडेम्पोटेंट होता है; चेकसम बेमेल (mismatch) को अस्वीकार कर दिया जाता है। रीलोड पर, वर्कर मैनिफ़ेस्ट पढ़ता है, सर्वर से स्वीकृत रेंज मांगता है, और केवल छूटे हुए सेट को अपलोड करता है।
3. UI को रिस्पॉन्सिव और रिकवरेबल बनाए रखें
निश्चित आकार के स्लाइस पढ़ें, एक समय में केवल एक सीमित बफ़र ट्रांसफ़र करें, और प्रोग्रेस इवेंट्स को थ्रॉटल करें ताकि रेंडरिंग पार्सिंग के साथ प्रतिस्पर्धा न करे। नेटवर्क प्रयास शुरू करने से पहले और प्रत्येक सर्वर पावती (acknowledgement) के बाद मैनिफ़ेस्ट को पर्सिस्ट करें। कैंसिलेशन अपलोड को स्थानीय रूप से चिह्नित करता है, सक्रिय अनुरोधों को निरस्त करता है, और क्लीनअप शेड्यूल करता है; इसे सर्वर द्वारा समाप्ति की पुष्टि करने से पहले एकमात्र रिकवरी मेटाडेटा को नहीं मिटाना चाहिए।
4. कोटा, अनुकूलता और सुरक्षा को संभालें
फ़ाइल कॉपी करने से पहले उपलब्ध स्टोरेज की जाँच करें और रिकवरेबल "स्टोरेज भरा हुआ है" स्थिति को प्रदर्शित करें। यदि OPFS अनुपलब्ध या एविक्ट हो गया है, तो उपयोगकर्ता द्वारा चुनी गई फ़ाइल पर फ़ॉलबैक करें और सर्वर-ज्ञात रेंज से पुनः प्रारंभ करें; उस मोड में कभी भी ऑफ़लाइन रीज़्यूम का वादा न करें। फ़ाइल नामों और पार्स की गई पंक्तियों को अविश्वसनीय मानें, प्रमाणित अपलोड ऑथराइजेशन की आवश्यकता रखें, और निजी स्थानीय पाथ को उजागर करने से बचें। रीलोड, ऑफ़लाइन अवधि, डुप्लिकेट चंक्स, चेकसम विफलता, टैब क्रैश, कोटा इनकार, और वर्कर पुनरारंभ का परीक्षण करें।
एक मजबूत नमूना उत्तर
मैं ब्राउज़र टार्गेट्स, पंक्तियाँ स्ट्रीम हो सकती हैं या नहीं, और रीलोड रिकवरी आवश्यक है या नहीं, इसे स्पष्ट करूँगा। क्लाइंट OPFS में एक मैनिफ़ेस्ट और सीमित अस्थायी चंक्स स्टोर करता है, जबकि एक वर्कर डिटर्मिनिस्टिक चंक आइडेंटिटी का उपयोग करके उन्हें पढ़ता और अपलोड करता है। सर्वर स्वीकृत रेंज के लिए आधिकारिक (authoritative) है; रीट्राई उस स्थिति के विरुद्ध रिकॉन्साइल करते हैं और चेकसम सत्यापित करते हैं। मेन थ्रेड केवल थ्रॉटल्ड प्रोग्रेस रेंडर करता है और कैंसिलेशन को नियंत्रित करता है। यदि स्टोरेज अनुपलब्ध है, तो UI सर्वर-साइड रीज़्यूम के साथ चुनी गई फ़ाइल फ्लो पर स्विच हो जाता है, लेकिन स्पष्ट रूप से ऑफ़लाइन पर्सिस्टेंस खो देता है। कोटा, एविक्शन, प्राइवेट-ऑरिजिन सेमांटिक्स और क्लीनअप अवलोकनीय (observable) स्थितियाँ हैं, छिपे हुए अपवाद नहीं।
सामान्य गलतियाँ
- पूरी फ़ाइल को मेमोरी में पढ़ना → 2 GB इनपुट टैब को फ्रीज़ या क्रैश कर देता है → वर्कर में सीमित चंक्स को स्लाइस करें।
- प्रोग्रेस प्रतिशत को पूर्ण सत्य मानना → खोई हुई पावती एक खाली जगह (hole) या डुप्लिकेट बनाती है → सर्वर के साथ स्वीकृत रेंज को रिकॉन्साइल करें।
- यह मान लेना कि OPFS एक उपयोगकर्ता-दृश्यमान फ़ोल्डर है → उपयोगकर्ता समान एक्सेस का निरीक्षण या अनुदान नहीं कर सकते हैं → ऑरिजिन-प्राइवेट स्टोरेज की व्याख्या करें और एक्सपोर्ट की आवश्यकता होने पर फ़ाइल हैंडल का उपयोग करें।
- केवल अपलोड सफलता के बाद पर्सिस्ट करना → एक क्रैश अगले रीट्राई पॉइंट को खो देता है → प्रयासों से पहले और पावती के बाद मैनिफ़ेस्ट को पर्सिस्ट करें।
- कोटा और एविक्शन को अनदेखा करना → उपयोगकर्ता कार्रवाई के बिना ऑफ़लाइन रिकवरी विफल हो जाती है → क्षमता की जाँच करें और एक स्पष्ट फ़ॉलबैक प्रदान करें।
- नाम या CSV फ़ील्ड पर भरोसा करना → स्थानीय डेटा सामग्री इंजेक्ट कर सकता है या पाथ लीक कर सकता है → इनपुट को मान्य करें और कभी भी स्थानीय पाथ विवरण को उजागर न करें।
फॉलो-अप प्रश्न और उत्तर
सर्वर द्वारा चंक प्राप्त करने के बाद लेकिन मैनिफ़ेस्ट अपडेट से पहले टैब क्रैश हो जाता है। अब क्या करें?
पुनरारंभ करने पर, सर्वर से स्वीकृत रेंज मांगें और उस प्रतिक्रिया को आधिकारिक मानें। गुम स्थानीय मैनिफ़ेस्ट प्रविष्टि को उसी चंक आइडेंटिटी के साथ फिर से अपलोड किया जा सकता है; सर्वर को डुप्लिकेट स्टोर करने के बजाय मौजूदा परिणाम लौटाना चाहिए।
ब्राउज़र रिपोर्ट करता है कि OPFS स्टोरेज को एविक्ट कर दिया गया था। क्या आप इंपोर्ट को विफल करते हैं?
अपलोड रिकॉर्ड रखें और समझाएं कि ऑफ़लाइन रीज़्यूम अब उपलब्ध नहीं है। उपयोगकर्ता से सोर्स फ़ाइल को फिर से चुनने के लिए कहें, फिर यदि सोर्स फ़िंगरप्रिंट मेल खाता है तो सर्वर-स्वीकृत रेंज से जारी रखें; अन्यथा एक नया अपलोड शुरू करें।
प्रत्येक इंपोर्ट के लिए यूज़र-विज़िबल डायरेक्टरी हैंडल का उपयोग क्यों नहीं करते?
यह एक परमिशन और जेस्चर फ्लो जोड़ता है और उत्पाद को एक ऐसे फ़ोल्डर से जोड़ता है जिसे उपयोगकर्ता बाहरी रूप से बदल सकता है। इसका उपयोग तब करें जब मूल फ़ाइल को संपादित या निर्यात करना आवश्यक हो; निजी अस्थायी चंक्स के लिए OPFS का उपयोग करें।
आप किसी वर्कर को नेटवर्क पर अत्यधिक ट्रैफ़िक (flooding) भेजने से कैसे रोकते हैं?
इन-फ़्लाइट चंक्स को सीमित करें, सर्वर या ब्राउज़र द्वारा बैकप्रेशर रिपोर्ट करने पर पढ़ने को रोकें, और नए काम की तुलना में रीट्राई को प्राथमिकता दें। कतार की गहराई (queue depth) और रीट्राई अवधि को प्रदर्शित करें ताकि UI धीमी प्रगति की व्याख्या कर सके।