osFoundry / Platform
Hot रीप्ले और इतिहास
हर चैनल अंतिम N दिनों के इवेंट्स रखता है। एक कर्सर रीसेट करें, किसी भी seq id से रीप्ले करें।
यह क्या है
Hot replay और हिस्ट्री osFoundry का प्रति-चैनल इवेंट लॉग है। हर चैनल, यानी आपके चैट, एजेंट और टूल्स के पीछे चलने वाली स्ट्रीम, पिछले N दिनों के इवेंट रखता है, और हर इवेंट के साथ एक monotonic sequence id (seq id) जुड़ी होती है। Consumers एक कर्सर को ट्रैक करते हुए आगे की ओर पढ़ते हैं, जो उनके द्वारा प्रोसेस किए गए आखिरी seq id की ओर इशारा करता है। चूँकि हाल की विंडो hot रखी जाती है, आपको किसी चैनल को fire-and-forget स्ट्रीम की तरह मानने की ज़रूरत नहीं है: हिस्ट्री वहीं मौजूद है ताकि उसे दोबारा पढ़ा जा सके।
मुख्य ऑपरेशन सरल है। कर्सर को किसी भी seq id पर वापस ले जाएँ और उसी बिंदु से रीप्ले करें। कोई एजेंट जो रन के बीच में क्रैश हो गया, कोई नया consumer जो अभी चैनल से जुड़ा है, या कोई टूल जिसने इवेंट गलत तरीके से प्रोसेस किए, ये सभी उसी सटीक क्रम को दोबारा पढ़ सकते हैं, बजाय इसके कि अंतराल खो दें या अंदाज़ा लगाएँ कि क्या हुआ था। चूँकि osFoundry एक bring-your-own-key डेस्कटॉप वर्कस्पेस है, यह हिस्ट्री किसी वेंडर के सर्वर पर नहीं, बल्कि आपके वर्कस्पेस के साथ रहती है। इवेंट विंडो local-first है, इसलिए पुराने इवेंट रीप्ले करने का मतलब आपका डेटा किसी तीसरे पक्ष को वापस भेजना नहीं है। आप कर्सर रीसेट करते हैं, रीप्ले करते हैं, और consumer उन्हीं क्रमबद्ध इवेंट को देखता है जो उसे लाइव दिखते।
यह क्यों मायने रखता है: एजेंट और मल्टी-चैनल वर्कफ़्लो stateful होते हैं, और वह state उतनी ही भरोसेमंद है जितनी उसे दोबारा बनाने की आपकी क्षमता। एक रिटेन की गई, seq-addressed विंडो "इस चैनल ने असल में क्या देखा?" वाले सवाल को अंदाज़े से बदल कर एक deterministic re-read बना देती है। इससे डिबगिंग reproducible बनती है (उसी सटीक क्रम को रीप्ले करें जिसने बग ट्रिगर किया), रिकवरी सस्ती होती है (शून्य से नहीं, आखिरी सही कर्सर से फिर शुरू करें), और नया consumer जोड़ना सुरक्षित होता है (चुने हुए seq id से backfill करें)। विंडो डिज़ाइन से पिछले N दिनों तक सीमित है, इसलिए हिस्ट्री बिना अनियंत्रित रूप से बढ़े उपयोगी और मौजूदा बनी रहती है।
मुख्य क्षमताएँ
- हर चैनल पिछले N दिनों के इवेंट रखता है, हर इवेंट पर एक monotonic sequence id (seq id) की मुहर लगी होती है
- किसी consumer के कर्सर को किसी भी seq id पर रीसेट करें और उसी बिंदु से इवेंट का सटीक, क्रमबद्ध अनुक्रम रीप्ले करें
- क्रैश हुए एजेंट या बीच में रुके रन को शुरू से करने के बजाय आखिरी प्रोसेस किए कर्सर से फिर शुरू कर के रिकवर करें
- उसी सटीक इवेंट अनुक्रम को रीप्ले कर के बग deterministically दोबारा बनाएँ जिसने उन्हें ट्रिगर किया, या नए जोड़े गए consumer को चुने हुए seq id से backfill करें
- सीमित, local-first रिटेंशन हाल की हिस्ट्री को आपके डिवाइस पर hot रखता है, बिना अनियंत्रित वृद्धि या वेंडर तक बार-बार जाए
उपयोग के मामले
- एजेंट डेवलपर: एक एजेंट रन के बीच में क्रैश हो जाता है, तो आप उसके कर्सर को आखिरी committed seq id पर वापस ले जाते हैं और चैनल रीप्ले कर के ठीक वहीं से फिर शुरू करते हैं जहाँ वह छूटा था
- वर्कफ़्लो डिबगर: एक downstream टूल ने गलत नतीजा दिया, तो आप उसी इवेंट रेंज को रीप्ले कर के उसे दोबारा बनाते हैं और deterministically पुष्टि करते हैं कि फ़िक्स काम कर रहा है
- इंटीग्रेशन बिल्डर: आप एक व्यस्त चैनल में नया consumer जोड़ते हैं और उसे चुने हुए seq id से backfill करते हैं ताकि लाइव होने से पहले वह पिछले N दिनों तक पहुँच जाए
सामान्य प्रश्न
मैं किसी चैनल में इवेंट कितने पीछे तक रीप्ले कर सकता हूँ?
हर चैनल पिछले N दिनों के इवेंट की एक rolling विंडो रखता है। उस विंडो के भीतर की हर चीज़ अपने sequence id से addressable है और रीप्ले की जा सकती है; रिटेंशन विंडो से पुराने इवेंट धीरे-धीरे expire हो जाते हैं, इसलिए hot replay हाल की हिस्ट्री और रिकवरी के लिए बना है, स्थायी archival के लिए नहीं।
कर्सर रीसेट करने से असल में क्या होता है?
एक कर्सर वह आखिरी seq id दर्शाता है जिसे किसी consumer ने प्रोसेस किया है। उसे किसी पहले वाले seq id पर रीसेट करना उस consumer को कहता है कि चैनल को उस बिंदु से आगे दोबारा पढ़े, और वही क्रमबद्ध इवेंट फिर से पाए। यह इवेंट को न मिटाता है न फिर से लिखता है, बस पढ़ाई कहाँ से फिर शुरू हो यह बदलता है।
मेरी चैनल हिस्ट्री रीप्ले करने से क्या डेटा osFoundry के सर्वर पर जाता है?
नहीं। osFoundry एक bring-your-own-key, local-first डेस्कटॉप वर्कस्पेस है, और इवेंट विंडो आपके वर्कस्पेस के साथ रिटेन होती है। रीप्ले उन्हीं इवेंट को दोबारा पढ़ता है जो पहले से लोकल रूप से रखे हैं, इसलिए हिस्ट्री रिकवर या दोबारा प्रोसेस करने के लिए आपका चैनल डेटा किसी तीसरे-पक्ष सेवा को भेजने की ज़रूरत नहीं।