Prokura naĝejo povas transformi simplan paneon en okupan buklon. Elektu adreson, malsukcesu, elektu alian, malsukcesu denove. Se ĉiu finpunkto estas neatingebla ĉar via propra reto paneis, ŝanĝi adresojn neniam riparas la kaŭzon.

Donu al la operacio buĝeton antaŭ ol elekti la unuan prokuron el via naĝejo aŭ la senpagan prokuran liston: finita nombro da provoj, limigitaj konekto- kaj legaj atendoj, kaj limdato por la tuta tasko. Requests-timeout regas sian dokumentitan konekto- aŭ legokonduton; ĝi per si mem ne limigas buklon, kiu daŭre eldonas novajn petojn.

Decidu, kio gajnas alian provon

  • Rifuzita prokura konekto povas pravigi provi alian finpunkton.
  • Respondo de la celo bezonas propran interpreton. Ricevi HTTP-eraron pruvas, ke iu petvojo finiĝis.
  • Prokura aŭtentiga malsukceso postulas kontroli la finpunkton kaj la konton, anstataŭ ripeti la samajn akreditaĵojn tra kreskanta listo.

Konservu la originalan escepton aŭ staton kun la provrekordo. Fina mesaĝo enhavanta nur «ĉiuj prokuroj malsukcesis» kaŝas, ĉu la malsukcesoj eĉ havis la saman kaŭzon.

Sana-kontrolado de ĉiu prokuro antaŭ ĉiu reala peto aldonas alian peton kaj ankoraŭ ne povas garantii, ke la sekva sukcesos. Reuzu freŝajn san-informojn kie ili taŭgas por la tasko, kaj lasu la realan operacion raporti sian propran rezulton.

Ripeto povas ripeti la laboron

Por nurlega elŝuto, transiri al alia prokuro kutime pli simplas ol ripeti sendaĵon. Se konekto falas post sendado de aĉeto aŭ formularo, la celo eble jam prilaboris ĝin. Sekvu la idempotencan mekanismon de la servo kaj la HTTP-ripetajn regulojn antaŭ ol ripeti laboron.

Kiam la buĝeto elĉerpiĝos, redonu utilan malsukceson. Tasko, kiu haltas kun pruvoj, pli facile ripareblas ol unu, kiu silente rotacias ĝis iu rimarkas.

Rilataj artikoloj