
ԱԲ գործակալը խափանվեց կես ճանապարհին․ մի կրկնեք արդեն վճարված կանչերը

Երկարատև ԱԲ գործակալը խափանումից հետո շարունակելու համար մոդելային և գործիքային կանչերը բաժանեք առանձին պահպանվող քայլերի։ Վերագործարկման ժամանակ վերցրեք ավարտված քայլերի արդյունքները և կատարեք միայն հաջորդ չավարտված գործողությունը։ Inngest-ի տևական կատարման նկարագրությունը ցույց է տալիս այս մեխանիզմը. ավարտված քայլի արդյունքը պահվում է, իսկ կրկնափորձը շարունակվում է վերջին հաջող քայլից։
Սահմանը կարևոր է. «արտաքին կանչն ավարտվել է» և «դրա արդյունքը պահպանվել է» տարբեր պահեր են։ Եթե պատասխանը կորել է դրանց միջև, տեղական գրառումը չի ասում՝ ծառայությունն արդեն կատարել է գործողությունը, թե ոչ։ Այդպիսի քայլը նախ ստուգեք արտաքին նույնացուցիչով կամ կրկնությունը ճանաչող բանալիով. միայն պահպանված արդյունք ունեցող վճարովի մոդելային կանչն է հնարավոր վստահորեն բաց թողնել։
Քայլ 1․ սահմանեք առանձին կրկնվող գործողությունները
Քայլի սահմանը դրեք այնտեղ, որտեղ գործողությունը պետք է ինքնուրույն ավարտվի, պահպանվի և հարկ եղած դեպքում կրկնվի։ Համատեքստի որոնումը, մոդելային կանչը, պատասխանի ստուգումը և արտաքին գործիքի կանչը մեկ քայլի մեջ միավորելու դեպքում վերջին գործողության ձախողումը կարող է կրկնել նաև նախորդները։ Դրանք բաժանելու դեպքում վերականգնումը կարող է օգտագործել որոնման և մոդելի արդեն գրանցված արդյունքները։
Տվեք յուրաքանչյուր քայլին կարճ, կայուն անուն, իսկ ամբողջ ընթացքին՝ առանձին նույնացուցիչ։ Քայլի անունը մի կազմեք փորձի համարից կամ ընթացիկ ժամից. նույն ընթացքի կրկնափորձը պետք է ճանաչի նույն գործողությունը։ Եթե ծրագրի նոր տարբերակում փոխում եք քայլերի հերթականությունը կամ ճյուղավորումը, նախ որոշեք, թե ինչպես են ավարտվելու արդեն սկսված ընթացքները։ Հին արդյունքը նոր տեղում օգտագործելը կարող է փոխել գործողությունների իմաստը։
Քայլ 2․ պահեք շարունակության համար անհրաժեշտ արդյունքը
Յուրաքանչյուր քայլի գրառումը կապեք ընթացքի նույնացուցիչին և պահեք քայլի անունը, մուտքի տարբերակը, կատարման վիճակը և հաջողության դեպքում՝ հաջորդ քայլին անհրաժեշտ արդյունքը։ Օգտակար վիճակներն են «սպասում է», «կատարվում է», «ավարտված է» և «ձախողվել է»։ «Ավարտված է» նշեք միայն այն ժամանակ, երբ արդյունքն արդեն հուսալիորեն գրանցված է։ Հակառակ դեպքում վերագործարկումը կարող է բաց թողնել աշխատանք, որի պատասխանը հաջորդ քայլին հասանելի չէ։
Մեծ պատասխանի դեպքում այն կարելի է պահել առանձին կայուն պահոցում, իսկ քայլի գրառման մեջ թողնել հղումն ու տարբերակը։ Պահպանվող վիճակի մեջ մի պատճենեք ամբողջ համատեքստը ամեն քայլից հետո. պահեք հենց այն արժեքները, որոնցից կախված է շարունակությունը։ Մուտքի տարբերակը կամ հեշը օգնում է տարբերել նույն ընթացքի կրկնափորձը փոխված նյութերով սկսված նոր աշխատանքից։ Այդ ստուգումը հատկապես կարևոր է, եթե մարդը հաստատում է նախագիծը, իսկ սկզբնական նյութերը հետո փոխվում են։
Պատկերացնենք պայմանական ընթացք. գործակալը գտնում է նյութերը, վճարովի մոդելային կանչով կազմում է պատասխանի նախագիծ, ապա արտաքին գործիքով ուղարկում է այն հաստատման։ Եթե նախագիծը պահպանվել է, իսկ ուղարկման քայլը ձախողվել է, վերագործարկումը վերցնում է պահված նախագիծը և աշխատում ուղարկման վրա։ Նույն նախագծի համար մոդելին կրկին դիմելը նոր ծախս է՝ առանց շարունակության համար անհրաժեշտ նոր արդյունքի։ Եթե նյութերը փոխվել են, սկսվում է նոր տարբերակ, և հին նախագիծը դրա պատրաստի արդյունքը չէ։
Քայլ 3․ արտաքին գործողությանը տվեք կայուն բանալի
Պահպանված արդյունքը պաշտպանում է ավարտված քայլերը, բայց ինքնուրույն չի երաշխավորում արտաքին գործողության եզակի կատարումը։ Inngest-ի գործնական կանոնները նկարագրում են դեպքը, երբ հարցումը հաջողվում է, սակայն քայլի արդյունքը չի հասցնում գրանցվել, և կրկնափորձը նորից ուղարկում է հարցումը։ Վճարման, հաղորդագրության ուղարկման կամ տվյալների փոփոխության համար այդ միջակայքը կարող է առաջացնել կրկնակի գործողություն։
Բանալին կազմեք ընթացքի և գործարար գործողության կայուն նույնացուցիչներից, ոչ թե կրկնափորձի համարից։ Նույն գործողության բոլոր փորձերը փոխանցում են նույն idempotency key-ն, եթե արտաքին ծառայությունն այն ընդունում է։ Եթե ծառայությունը նման բանալի չի ընդունում, պահեք գործողության եզակի գրառում և, հնարավորության դեպքում, արտաքին համակարգի տված արդյունքի նույնացուցիչը։ Միայն ձեր տվյալների բազայում եզակի գրառում ունենալը բավարար չէ, եթե արտաքին համակարգը չի թույլ տալիս պարզել՝ հարցումն այնտեղ կատարվել է արդյոք։
Մոդելային ծառայության դեպքում առանձին պարզեք՝ հնարավո՞ր է նույն հարցումը ճանաչել կամ նախկին պատասխանը վերցնել հարցման նույնացուցիչով։ Եթե նման հնարավորություն չկա, տեղական checkpoint-ը չի վերադարձնի արդեն կատարված, բայց չգրանցված պատասխանը և չի վերացնի դրա հնարավոր վճարը։ Այդ անորոշությունը տարբերեք այն դեպքից, երբ մոդելային քայլի պատասխանը պահպանված է. վերջինիս կրկնել պետք չէ։
Քայլ 4․ դասակարգեք սխալը մինչև կրկնափորձը
Ժամանակավոր ցանցային խափանումը կամ ծառայության հասանելիության խնդիրը կարող է արդարացնել նույն քայլի սահմանափակ կրկնափորձը՝ ուշացումով։ Սխալ մուտքը, թույլտվության բացակայությունը կամ պահանջներին չհամապատասխանող անփոփոխ հարցումը նույն ձևով կրկնելու պատճառ չեն։ Դրանք նշեք որպես շտկում պահանջող ձախողումներ։ Կրկնափորձերի քանակը, ուշացումը և վերջնաժամկետը որոշեք ըստ գործողության արժեքի, արտաքին ծառայության սահմանափակումների և կրկնակի կատարման հետևանքի։
Առանձին պահեք «արդյունքն անհայտ է» վիճակը։ Օրինակ՝ արտաքին ծառայության հարցումը ավարտվել է timeout-ով, բայց ծառայությունը կարող էր արդեն կատարել այն։ Նախ փորձեք գտնել արդյունքը նույն բանալիով կամ հարցման նույնացուցիչով, հետո միայն որոշեք կրկնելու մասին։ Անվնաս ընթերցումը սովորաբար կարելի է նորից կատարել. վճարովի մոդելային կանչի կամ արտաքին փոփոխության դեպքում անորոշությունը կարող է պահանջել ձեռքով որոշում։ Այս տարբերակումը թույլ չի տալիս տեխնիկական timeout-ը շփոթել հաստատված ձախողման հետ։
Քայլ 5․ մարդու հաստատումը պահեք որպես սպասող վիճակ
Մարդու որոշմանը սպասող ընթացքը մի պահեք միայն բաց գործընթացի հիշողության մեջ։ Գրանցեք ընթացքի նույնացուցիչը, հաստատման ենթակա բովանդակության տարբերակը և սպասվող որոշումը, ապա հաստատումը կամ մերժումը ընդունեք այդ ընթացքին կապված իրադարձությամբ։ Temporal-ի Durable AI նկարագրությունը ներառում է գործակալային հոսքեր, որոնք շարունակում են աշխատանքը խափանումից, ցանցային timeout-ից կամ մարդու բազմօրյա հաստատման սպասումից հետո։
Հաստատումից հետո վերցրեք արդեն պահված նախագիծը և անցեք միայն թույլատրված հաջորդ գործողությանը։ Որոշման գրառումը կապեք հաստատված տարբերակին, որպեսզի նույն իրադարձության կրկնակի առաքումը երկրորդ ուղարկում չառաջացնի, իսկ բովանդակության փոփոխությունը հին հաստատմամբ չանցնի։ Մերժման դեպքում ավարտեք այդ ճյուղը կամ բացեք նոր տարբերակ՝ նոր մուտքով ու նոր որոշմամբ։ Այսպես սպասումը դառնում է ընթացքի պահպանված վիճակ, իսկ շարունակությունը սկսվում է հաստատումից հետո նախատեսված քայլից։
Կարդացեք նաև:
Առնչվող հոդվածներ


LangGraph թե CrewAI․ գրաֆային վերահսկո՞ւմ, թե դերային թիմ

Claude API թե OpenAI API․ էժան token-ը դեռ էժան task չէ

OpenAI Agents SDK թե LangGraph․ արագ մեկնարկը բախվում է վերականգնվող վիճակին

AutoGen թե CrewAI․ արագ նախատիպը բախվում է maintenance mode-ին

PydanticAI թե LangGraph․ պարզ Python-ը բախվում է վերականգնվող գրաֆին
Բաժանորդագրվեք մեր տեղեկագրին
Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։