Declanșarea unui flux ar trebui să întoarcă identitatea execuției

O automatizare care pornește o activitate ar trebui să păstreze identitatea execuției create. Căutarea ulterioară a celei mai recente execuții răspunde la altă întrebare: care execuție este cea mai nouă în momentul căutării. Într-un depozit fără activitate concurentă, răspunsurile pot coincide. Când mai multe persoane folosesc fluxul simultan, diferența afectează corectitudinea. Identitatea întoarsă direct de cerere oferă o legătură explicită între apel și execuție.

Anunțul GitHub din 19 februarie 2026 a introdus un răspuns opțional pentru declanșarea fluxurilor de lucru. Articolul de față privește săptămâna începută pe 18 februarie. Subiectul este contractul din februarie, fără presupunerea că toate versiunile API sau toate aplicațiile disponibile în noiembrie se comportă identic. Distincția contează pentru integrările care așteaptă un răspuns gol.

Cea mai recentă execuție poate aparține altui apel

Imaginați-vă două aplicații care declanșează același flux pe aceeași ramură. Una cere pregătirea unei versiuni candidate; cealaltă cere o verificare separată. Ambele cereri pot ajunge înainte ca vreuna dintre aplicații să ceară lista execuțiilor. Alegerea primului rezultat, ordonat după dată, nu stabilește ce cerere l-a produs. Numele fluxului și ramura restrâng lista, dar pot fi comune mai multor execuții legitime.

O întârziere nu repară relația lipsă. Așteptarea poate face vizibilă o execuție, dar lasă și timp pentru apariția altora. O pauză scurtă schimbă momentul căutării fără să dovedească identitatea. Întrebarea utilă este dacă răspunsul numește execuția creată de cererea respectivă. Dacă da, aplicația poate păstra identitatea înainte să urmărească progresul.

Aceasta este o interpretare a utilității interfeței, nu relatarea unei erori de concurență observate local ori a unei îmbunătățiri măsurate a interogărilor periodice. Avantajul privește sensul legăturii dintre cerere și rezultat. O integrare nu ar trebui să depindă de lipsa altor activități pentru a ști ce execuție urmărește.

Păstrați explicit alegerea răspunsului nou

Anunțul din februarie descria parametrul boolean opțional return_run_details. Activarea lui producea un răspuns 200 OK, cu date de identificare; omiterea păstra 204 No Content. Anunțul indica și GitHub CLI v2.87.0 drept versiune care acceptă schimbarea prin gh workflow run. Înregistrarea separată a versiunii CLI ține de istoricul lansărilor; anunțul oferă afirmația datată despre compatibilitate.

Această limită păstrează compatibilitatea. O aplicație care verifică strict codul 204 poate respinge un răspuns 200 reușit dacă implementarea ei nu a fost adaptată. La migrare, stabiliți când activați parametrul, cum validați identitatea primită și unde o păstrați. Acceptarea tuturor codurilor de succes, cu ignorarea în continuare a corpului răspunsului, ar rata scopul schimbării.

Documentația actuală a fluxurilor ilustrează câmpurile workflow_run_id, run_url și html_url. Ele deosebesc identificatorul execuției, adresa API și adresa pentru browser. Documentația se poate modifica; secțiunea actuală arată un răspuns 200 fără să reproducă descrierea parametrului opțional din februarie. Folosiți anunțul datat pentru afirmația istorică despre activarea opțională. Schema documentată astăzi nu trebuie prezentată drept schemă neschimbată din februarie.

Păstrați identitatea înainte să raportați progresul

După primirea identității, aplicația ar trebui să folosească aceeași execuție pentru urmărirea stării. Înlocuirea ei cu o nouă căutare a celei mai recente execuții, la recuperarea după o eroare, ar readuce ambiguitatea. În principiu, o înregistrare a operațiunii poate lega cererea inițială de execuția întoarsă. Persoana care investighează poate astfel consulta aceeași execuție pe care o urmărește automatizarea. Aceasta este o recomandare de proiectare, nu descrierea unei implementări de stocare existente.

Identitatea separă și declanșarea de finalizare. Primirea unui identificator nu înseamnă că fluxul a reușit. Aplicația poate avea în continuare de urmărit așteptarea, executarea și rezultatul final, apoi de decis ce rezultat contează pentru operațiunea proprie. Mesajul afișat ar trebui să spună doar ce s-a stabilit. „Creată” și „încheiată cu succes” sunt afirmații diferite.

Adresa pentru browser ajută investigația, dar nu acordă acces tuturor destinatarilor ei. Vizibilitatea depozitului și autorizarea persoanei rămân relevante. Includerea adresei într-o notificare ar trebui, așadar, decisă explicit, mai ales când mesajele sau jurnalele ajung la un public mai larg decât cel al depozitului.

Identificatorul nu elimină dublarea la repetare

Limita cea mai importantă apare când serverul acceptă cererea, dar răspunsul nu mai ajunge la apelant. Serverul poate să fi creat execuția, în timp ce aplicația nu are identitatea de păstrat. Repetarea cererii poate crea o altă execuție. Întoarcerea unui identificator în răspunsurile reușite nu promite, prin ea însăși, că cererile repetate se reduc la o singură executare.

Eroarea cu rezultat necunoscut cere o politică proprie. În funcție de consecințele fluxului, integrarea poate opri continuarea până la lămurirea situației sau poate folosi un mecanism de eliminare a duplicatelor, proiectat separat. Nu trebuie să presupună că mecanismul există doar fiindcă API-ul întoarce un ID. Identificatorul descrie o execuție; garanția privind repetarea unei operațiuni privește efectul apelurilor repetate. Confundarea lor ascunde riscul rămas.

Aceeași distincție se aplică unei persoane care apasă de două ori butonul de pornire. Două cereri valide pot produce totuși muncă duplicată nedorită. Tratarea operațiunilor de afaceri repetate rămâne o decizie separată în fluxul care le execută. Schimbarea din februarie îmbunătățește corelarea fără să rezolve această decizie pentru aplicație.

În dezvoltarea software la comandă, faceți verificabile ambele contracte: cum legați cererea de o execuție și ce se întâmplă când rezultatul cererii rămâne necunoscut. Schimbarea GitHub elimină o deducție fragilă din cazul obișnuit de succes. Integrarea mai are nevoie de un răspuns onest pentru momentul în care răspunsul serverului nu ajunge.