Բազմավարձակալություն և իդեմպոտենտություն

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer-ը **բազմավարձակալ** է. մեկ gateway-ը կարող է սպասարկել շատ աշխատանքային տարածքներ մեկ տվյալների բազայից՝ պահելով նրանց տվյալները առանձին։ Երկու մեխանիզմ դա անվտանգ են դարձնում — **Postgres Row-Level Security (RLS)** կարդալ/գրել մեկուսացման համար, և **իդեմպոտենտության շերտ**, որպեսզի վերափորձերն ու turn-ի վերականգնումը երբեք չկրկնեն իրական աշխարհի կողմնակի էֆեկտը։ ## Tenant-ի մեկուսացում Row-Level Security-ով Մեկուսացումը կիրառվում է տվյալների բազայում, ոչ թե միայն հավելվածի կոդում։ AiHummer-ը հարցումներ է աշխատեցնում **սահմանափակ Postgres role**-ի (`aihummer_app`) միջոցով, որին կիրառված են RLS քաղաքականություններ, ուստի տվյալների բազան ինքնին մերժում է այն տողերը, որոնք չեն պատկանում ակտիվ tenant-ին։ RLS-ն **ընտրովի-միացվող** է։ Դուք այն ակտիվացնում եք՝ gateway-ին տալով երկրորդ կապի string սահմանափակ role-ի համար. ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > Host-native տեղադրումների համար տեղադրիչը սահմանում է `AIHUMMER_DB_APP_URL`-ը > ավտոմատ կերպով, ուստի RLS-ն ստանդարտ տեղակայման մեջ ըստ լռելյայնի միացված է։ > Եթե փոփոխականը բացակայում է, gateway-ն աշխատում է միայն owner pool-ի վրա, և > RLS-ն ակտիվ չէ։ ### Ըստ tenant-ի շրջանակավորում Սահմանափակ role-ի ներսում յուրաքանչյուր հարցում շրջանակավորվում է իր tenant-ով. gateway-ը կապի վրա սահմանում է ընթացիկ tenant-ի համատեքստը, որպեսզի RLS քաղաքականությունները լուծվեն ճիշտ աշխատանքային տարածքի դեմ։ `WHERE tenant_id = …` ֆիլտրերը ձեռքով գրված չեն ամենուր. քաղաքականությունը կիրառում է դա կենտրոնականորեն, ինչը նշանակում է, որ բաց թողնված ֆիլտրը չի կարող արտահոսել մեկ այլ tenant-ի տողերը։ ### Համակարգ / bypass ռեժիմ Որոշ աշխատանք օրինականորեն խաչ-tenant է — ֆոնային worker-ներ, ժամանակացույցեր և սպասարկման աշխատանքներ, որոնք գործում են ամբողջ instance-ի վրայով։ Դրանք աշխատում են **համակարգ / bypass ռեժիմում**, որպեսզի կարողանան տեսնել այն, ինչ պետք է։ Bypass-ը վերապահված է վստահելի ներքին worker-ների համար, ոչ թե հարցում մշակող ուղիների։ > [!WARNING] > **Migration-ները միշտ աշխատում են owner pool-ի վրա**, երբեք սահմանափակ role-ի > ներքո։ Owner կապը ունի սխեման փոփոխելու և RLS քաղաքականություններ կիրառելու > արտոնություններ. սահմանափակ role-ը դիտավորյալ չունի։ Պահեք երկու կապի > string-երը տարբեր և `aihummer_app` role-ին տվեք միայն այն, ինչ պետք է։ ## Իդեմպոտենտ կողմնակի էֆեկտներ Turn-ը կարող է ստեղծել իրական աշխարհի կողմնակի էֆեկտներ. նամակ ուղարկել, հաղորդագրություն հետ տեղադրել ալիք։ Եթե turn-ը վերափորձվում է — անցողիկ սխալի պատճառով, կամ որովհետև gateway-ը վերագործարկվել է turn-ի կեսին, և վերականգնումը այն վերարտադրում է — այդ կողմնակի էֆեկտները **չպետք է** տեղի ունենան երկու անգամ։ AiHummer-ը երաշխավորում է սա երկու համագործակցող մասով։ ### Վերսկսման հարցում կայուն ledger key Յուրաքանչյուր կողմնակի էֆեկտ գրանցվում է **վերսկսման հարցում կայուն ledger key**-ի դեմ. key, որը դետերմինիստականորեն ստացվում է turn-ից, ուստի նույն turn-ի վերարտադրությունը հաշվարկում է *նույն* key-ը, այլ ոչ թե նորը։ Ledger-ը հիշում է, թե որ key-երն արդեն գործողության են ենթարկվել։ ### Կողմնակի էֆեկտի արգելապատնեշ Նախքան **նամակի** կամ **ալիք-ուղարկման** նման էֆեկտ կատարվելը, այն անցնում է **կողմնակի էֆեկտի արգելապատնեշով**, որը ստուգում է ledger-ը։ Եթե այս key-ն արդեն գործարկվել է, արգելապատնեշը կարճ-միացում է անում, և էֆեկտը բաց է թողնվում. եթե ոչ, էֆեկտն աշխատում է, և key-ը commit-վում է։ ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Արդյունքը **ճիշտ-մեկ-անգամ արտաքին վարքագիծ է, թեև առաքումը ներքին մակարդակում առնվազն-մեկ-անգամ է**։ Վերափորձերն ապահով են ըստ կառուցվածքի, ինչը հենց թույլ է տալիս turn-ի վերականգնմանը (տես [Առաքում, outbox և վերականգնում](/hy/v1.0/architecture/delivery-outbox)) վերարտադրել ընդհատված turn-ը՝ առանց հաճախորդի՝ նույն նամակը կամ նույն պատասխանը երկու անգամ ստանալու։ > [!TIP] > Հենց դրա համար է AiHummer-ը կարող առաջարկել երաշխավորված առաքում և > ավտոմատ turn-ի վերականգնում՝ առանց կրկնակի հաղորդագրությունների սովորական > ռիսկի — իդեմպոտենտությունը այն հիմքն է, որի վրա կառուցված են առաքման > երաշխիքները։ ## Ուր հաջորդիվ - Runtime-ը, որը վարում է turn-ը. [Gateway և turn engine](/hy/v1.0/architecture/gateway-turn-engine)։ - Ինչպես են պատասխանները վերադարձվում ճիշտ մեկ անգամ. [Առաքում, outbox և վերականգնում](/hy/v1.0/architecture/delivery-outbox)։