Virheestä palautuminen ja ristiriitojen ratkaiseminen

Optimistisen lisäyksen palauttaminen (kohteen poistaminen) tai poistamisen palauttaminen (kohteen palauttaminen) on suoraviivaista. Päivityksen palauttaminen on monimutkaisempaa: täsmälleen aiempi arvo on palautettava. Jos kohdetta on päivitetty optimistisesti useita kertoja, jokainen aiempi arvo on tallennettava erikseen, ei pelkästään alkuperäistä palvelimen tilaa.

Ajatellaan seuraavaa tilannetta: palvelimella kohteen arvo on Z. Päivitätte sen optimistisesti arvoksi X. Kun pyyntöänne käsitellään, toinen käyttäjä päivittää saman kohteen palvelimella arvoksi Y. Pyyntönne saapuu palvelimelle, joka hylkää sen (ristiriita). Palautuksen kohteena on Z, mutta palvelimen nykyinen tila on Y. Arvon Z palauttaminen korvaisi arvon Y virheellisesti.

Turvallisin tapa palauttaa päivitykset on hakea kohde palvelimelta uudelleen jokaisen mutaatiovirheen jälkeen sen sijaan, että palauttaisitte paikallisesti tallennetun tilannevedoksen. Näin näytätte aina palvelimen auktoritatiivisen tilan riippumatta siitä, mitä muut käyttäjät ovat samanaikaisesti muuttaneet. Uudelleenhaku on hitaampaa, mutta aina oikein.

Hyvin suunniteltu API palauttaa HTTP 409 Conflict -tilan, kun optimistinen päivitys epäonnistuu samanaikaisen muutoksen vuoksi. Vastauksen runko sisältää yleensä palvelimen nykyisen tilan. Virheenkäsittelijän tulee tunnistaa 409-ristiriita, päivittää paikallinen tila vastausrunkoa käyttäen palvelimen nykyiseen arvoon ja ilmoittaa käyttäjälle, ettei hänen muutoksiaan tallennettu.

Idempotentti mutaatio tuottaa saman tuloksen, vaikka se suoritettaisiin useita kertoja. Kun mutaatiot suunnitellaan idempotenteiksi (käyttämällä PUT-metodia POST-metodin sijaan, sisällyttämällä mukaan resurssin koko tila ja käyttämällä idempotenssiavaimia), pyynnön uudelleenyritys virheen jälkeen on turvallista ilman muutoksen toistumisen riskiä. Tämä yksinkertaistaa palautuslogiikkaa huomattavasti.

Lähetä-painikkeen kaksoisnapsautus voi käynnistää kaksi samanlaista mutaatiota. Estäkää tämä isSubmitting-lipulla: asettakaa sen arvoksi true mutaation alkaessa ja palauttakaa arvo mutaation valmistuessa onnistumisesta tai epäonnistumisesta riippumatta. Poistakaa laukaisuelementti käytöstä, kun isSubmitting on true. Näin päällekkäiset mutaatiot voidaan estää käyttöliittymän tasolla.

Palvelimen suorittamaa kaksoiskappaleiden estämistä varten lisätkää jokaiseen mutaatiopyyntöön yksilöllinen Idempotency-Key-otsake. Luokaa se komennolla crypto.randomUUID(), kun käyttäjä käynnistää toiminnon. Palvelin tunnistaa kaksoiskappaleiset avaimet ja palauttaa saman vastauksen kuin alkuperäisen pyynnön yhteydessä suorittamatta operaatiota uudelleen.

Kun mutaatiota käsitellään, voitte näyttää hienovaraisen ilmaisimen siitä, ettei optimistista tilaa ole vielä vahvistettu: esimerkiksi pienen sykkivän pisteen, tekstin "Tallennetaan..." tai kohteen pienemmän peittävyyden. Tämä ilmaisee epävarmuuden estämättä vuorovaikutusta. Poistakaa ilmaisin onnistumisen jälkeen tai palauttakaa tila virheen sattuessa.

Palautuslogiikan odottamattomat virheet (esimerkiksi määrittelemättömän arvon ominaisuuksien käsitteleminen tilaa palautettaessa) voivat kaataa komponentin. Ympäröikää paljon mutaatioita sisältävät komponentit virherajalla, jotta vakavat palautusvirheet näyttävät tyhjän ruudun sijaan hallitun virhenäkymän. Kirjatkaa nämä virheet lokiin vianmääritystä varten.

Luotettava tapa havaita ristiriidat on sisällyttää versionumero tai ETag jokaiseen mutaatioon. Palvelin vertaa asiakkaan lähettämää versiota omaan nykyiseen versioonsa. Jos versiot eroavat toisistaan (toinen päivitys on tehty), palvelin palauttaa tilan 409. Tämä on optimistista samanaikaisuuden hallintaa: oletatte, ettei ristiriitaa ole, mutta havaitsette sen, jos se ilmenee.

Palautuslogiikka jää usein testaamatta, koska verkkovirheitä on vaikea simuloida. Käyttäkää testeissä esimerkiksi Mock Service Worker (MSW) -työkaluja virhevastausten palauttamiseen. Kirjoittakaa erilliset testit seuraaville tapauksille: 409 Conflict -tilan käsittely, verkkoyhteyden aikakatkaisun jälkeinen palautus, kaksoisnapsautusten estäminen ja tilan eheys virheen jälkeen. Virheet piilevät usein juuri näissä poikkeustapauksissa.

Päivityksen palauttaminen on monimutkaisempaa kuin lisäyksen tai poiston: hakekaa aina tiedot uudelleen virheen sattuessa, jotta vältätte vanhoihin tilannevedoksiin liittyvät ongelmat. HTTP 409 Conflict ilmaisee optimistisen samanaikaisuuden hallinnan epäonnistumisen; käyttäkää vastausrunkoa palvelimen nykyisen tilan palauttamiseen. Suunnitelkaa mutaatiot idempotenteiksi, jotta niiden uudelleenyritys on turvallista. Estäkää kaksoiskäynnistykset isSubmitting-tilan ja palvelimen idempotenssiavainten avulla. Testatkaa palautuspolut erikseen käyttämällä MSW:tä virheiden simulointiin.