Alan olayları

Alan olayı nedir

Alan olayları, özelliklerin doğrudan bağımlılıklar olmadan iletişim kurmasını sağlayan ayrıştırma mekanizmasıdır. A özelliği B özelliğini çağırmak yerine, A özelliği bir olay yayımlar ve B özelliği ona abone olur.

DomainEventBus, süreç içi çalışan, yayın tabanlı bir yayınla/abone ol veri yoludur. Yayıncılar publish(event) çağırır; aboneler tipli bir on<T>() akışı tüketir. Her olay DomainEvent uygular ve occurredAt taşır.

Veri yolu cc_server içinde çalışır. Her yayıncı ve her canlı abone orada yaşar. Hiçbir istemci bu veri yolunu görmez. Bir istemcinin gördüğü şey, sunucunun notifications/* JSON-RPC çerçeveleri olarak yeniden yayımladığı özenle seçilmiş bir alt kümedir.

Neden bir veri yolu?

Olaylar olmadan, özellikler arası her tepki bir içe aktarmadır. Bildirim modülü, yalnızca ne zaman bildirim balonu göstereceğini bilmek için ajanlar özelliğini, pull request özelliğini, biletlemeyi ve toplantıları içe aktarmak zorunda kalırdı — ve bunların her biri de bildirimlerin var olduğunu bilmek zorunda kalırdı. Biletleme, tamamlanan bir biletin bir çalıştırmayı ilerletebilmesi için pipeline’ları içe aktarırdı. Bağımlılık grafiği kördüğüme dönüşür ve paylaşılan çekirdek artık paylaşılan olmaktan çıkar.

Bir olay yayımlamak bunu kırar. Bildirim modülü yirmi bir olay sınıfına abone olur ve bunları doğuran özelliklerin hiçbirini içe aktarmaz. Pipeline tetikleyici dağıtıcısı tüm veri yoluna abone olur ve pull request’ler, biletler ya da toplantılar hakkında hiçbir şey bilmez. Gözlemlenebilirlik toplamaları, gönderim katmanına uzanmadan çalıştırma sonuçlarını bir araya getirir.

Bunun bedeli her zamanki bedeldir: bir yayıncı kimsenin dinleyip dinlemediğini anlayamaz ve hiç oluşturulmayan bir dinleyici sessizce etkisiz kalır. TicketRemoteSyncHandler bunun süregelen örneğidir: tanımlanmıştır, testlerle kapsanmıştır ve üretimde hiç bağlanmamıştır.

Veri yolu ne değildir

Veri yolunun sahip olmadığı bir konuda kesin olmakta fayda var.

Denetim kaydı, olay akışının bir yansıması değildir. Durumu değiştiren her RPC işlemi varsayılan olarak denetlenir — RepoOp.audited varsayılan olarak true değerini alır ve bir işlem yalnızca audited: false bildirerek bundan çıkar; bu, işlemin kendisinde görülebilen bilinçli bir eylemdir. Dağıtıcı, başarılı bir çağrının hemen ardından “kim, neyi, nereden yaptı” satırını ekler. DomainEventAuditBridge diye bir şey yoktur. ActivityLogPersister, ActivityLogged olaylarından activity_log satırlarını yazar; bu, RPC denetiminden ayrı bir beslemedir.

Olay veri yolu, bildirimlerin ve otomasyonun taşıyıcısıdır. Kayıtların tutulduğu asıl sistem değildir.

Veri yolunun yürüttükleri

Bildirimler. Yirmi bir olay sınıfı sunucu tarafından notifications/* iletişim çerçevelerine dönüştürülür, çalışma alanı başına kalıcı bir akışa kaydedilir ve bağlı oturumlara yayınlanır. workspace_id değeri, oturum kullanıcısının üyesi olmadığı bir çalışma alanını belirten bir çerçeve sunucuda düşürülür; istemci de kalanları baktığı çalışma alanına göre süzer.
Olay güdümlü otomasyon. Pipeline tetikleyicileri veri yoluna abone olur ve eşleşen pipeline’ları otomatik başlatır (aşağıya bakın).
Yaşam döngüsü tepkileri. Bir çalışma alanı oluşturmak; CEO’sunu ve uzman ajanlarını, yerleşik pipeline şablonlarını ve başlangıç eval paketlerini hazırlar. Tamamlanan bir ajan çalıştırması, askıya alınmış bir pipeline adımını sürdürür, bir görevi kapatır, hedef gözetmenini besler, adlandırılmış bir denetleyiciyi uyandırabilir ve bir ekip liderini yeniden tetikleyebilir. Birleştirilmiş bir PR ya da silinmiş bir alan, çalışma ağacı çöp toplamayı tetikler.
Sağlayıcılar arası eşitleme. Yerel bilet değişiklikleri, beş bilet olayını dinleyen bir koordinatör tarafından yapılandırılmış sağlayıcılara gönderilir.

Olay kategorileri

Olaylar tüm ürün yüzeyine yayılır. Üst düzeyde:

Çalışma alanları, ajanlar ve depolar — çalışma alanı oluşturma, çalıştırma tamamlanması, depo kaydı, beceri güncellemeleri
Pull request’ler — yayımlama, durum değişiklikleri, birleştirmeler, inceleme istekleri, anmalar, yazdığınız PR’ları izleme, dışarıdan algılanan PR’lar
Mesajlaşma — mesajlar, alanlar ve alan sağlama ilerlemesi
Biletler — oluşturma, atama, yeniden atama, ayrıntılar, durum ve üç nihai sonuç
Görevler — tek bir gönderilmiş çalıştırma için sıralanmış yaşam döngüsü çerçeveleri; böylece istemciler bunları sıralayıp yinelenenleri ayıklayabilir
Pipeline’lar — yalnızca nihai çalıştırma olayları (tamamlandı, iptal edildi, başarısız oldu)
Gözlemlenebilirlik — etkinlik günlüğü girdileri ve bütçe eşikleri
Kimlik ve üyelik — üye eklendi, çıkarıldı, rol değişti
Takvim ve toplantılar — kimlik doğrulama süresinin dolması, toplantıların başlaması ve kayıtların tamamlanması
Rig’ler — devralma, toplama ve beklenmeyen kapanma

Bellek, orkestrasyon, plan belgeleri, artifaktlar, onaylar, bilet eşitleme alımı, takvim yenilemesi, çalışma ağacı birleştirmeleri, kullanıcı oluşturma, davetler ve cihaz iptali alan olayı değildir; referansa bakın.

Eksiksiz katalog için — 53 somut olay sınıfının tümü, yükleri ve bunları tüketen 24 abone — Alan olayları referansına bakın. O sayfa envanterdir; bu sayfa ise modeldir.

Canlı erişim denetimi iki farklı mekanizmaya yaslanır

Üyelik ve cihaz olayları simetrik görünür ama değildir; bir iptalin ne kadar hızlı etkili olduğunu düşünüyorsanız bu önemlidir.

Bir cihazı iptal etmek, oturumlarını gerçekten sonlandırır. Sunucu, eşleştirilmiş cihaz tablosunu izler ve cihazı etkin kümeden çıkan her canlı oturumu saniyeler içinde düşürür.

Bir üyeyi çıkarmak soketi kapatmaz. WorkspaceMemberRemoved tüketilir: LocalRpcServer ve RemoteRelayHost o kullanıcının bağlı çalışma alanı aboneliklerini düşürür ve RemoteEventForwarder, üyelik önbelleğini geçersiz kılar; böylece o çalışma alanı için sonraki çerçeveler gönderilmez. Bir sonraki RPC’yi reddeden şey yine rol denetimidir; bu denetim üyeliği her çağrıda yeniden çözer — dolayısıyla bir sonraki istekleri “Not a member of this workspace” hatasıyla reddedilir. Yapmaya çalıştıkları her şey için etki anındadır; bu yalnızca bağlantılarını kapatarak sağlanmaz.

Pipeline tetikleyicileri

Pipeline tetikleyicileri alan olaylarına abone olur ve eşleşen pipeline’ları otomatik başlatır. PipelineTriggerDispatcher tüm veri yolunu dinler, ardından:

Olay türü, bir yüke nasıl eşleneceğini bildiği bir tür değilse kısa devre yapar
Her çalışma alanında, o olay türüyle eşleşen etkin tetikleyicileri arar
Her birini kendi çalışma alanına göre süzer ve yük eşleme filtresini uygular
Ayakta kalan her tetikleyici için bir çalıştırma başlatır

Önemli kısıt 1. adımdır. Veri yolu 53 olay türü taşır; tetikleyici ekleme seçicisi bu on dört tür için çalıştırma başlatır (EventPayloadMapper yük dalları): ExternalPrDetected, PullRequestPublished, PullRequestStatusChanged, PrMerged, MessageReceived, TicketAssigned, TicketCompleted, TicketFailed, TicketCancelled, BudgetThresholdCrossed, RepoAdded, MeetingRecordingStopped, SkillUpdated ve SpaceDeleted. Başka hiçbir şey bir pipeline’ı başlatamaz.

Bir istemci tüm bunları nasıl görür

RemoteEventForwarder, bildirim sınıfındaki olayları iletişim çerçevelerine çevirir ve bunları RPC üzerinden bağlı oturumlara iter; burada bir çerçeve eşleyici bunları uygulama içi bildirimlere dönüştürür. Bu nedenle ince bir istemci, hiçbir yürütmeye sahip olmadan sunucunun olay akışının bir yansımasını görür — ince istemci ayrımının tüm amacı da budur.

Ancak itilen her çerçeve bir bildirim değildir. Görev yaşam döngüsü akışı ve bilet yeniden ataması, arayüzü yürütmek için canlı olarak iletilir; ancak bildirim akışına kaydedilmez ve bildirim balonu göstermez.

Ayrıca bakınız

Pipeline’lar ve otomasyon: bir tetikleyicinin neyi başlattığı
Biletler ve devretme: bir ajana mı yoksa bir ekibe mi atama
Mimari: olayların bağımlılık kuralına nasıl oturduğu
Alan olayları referansı: eksiksiz katalog ve aboneleri
Pipeline tetikleyicileri kurma
Bildirimleri yapılandırma