Kapag gumagawa ang isang Agent ng web tasks, madalas nagmumula ang failure sa apat na bahagi: paghanap ng element, paghihintay at timeout, pag-save ng state, at pag-block ng environment. Mas nagiging stable ang success rate kapag idempotent ang bawat hakbang, nire-retry ang recoverable failures, ipinipersist ang state, at hiwalay ang environment ng bawat task.
Kapag nagsisimula sa web automation, karaniwang diretso ang unang ideya: ilatag ang flow at patakbuhin ang script. Mukhang tama ang logic, pero paminsan-minsan ay bumabagsak pa rin ang mga task at nagkakaroon ng kakaibang state ang account. Unang hinala ang code, ngunit sa mas malalim na pag-troubleshoot, kadalasang nauuwi sa apat na bahagi ang problema.
Kapag nagbago ang page, puwedeng masira ang element targeting
Karamihan sa scripts ay gumagamit ng selectors para hanapin ang elements. Kapag hard-coded ang selector, halos anumang pagbabago sa page ay maaaring magpabagsak dito: nagpalit ng class name ang button, nabago ang isang salita sa copy, lumipat ang isang section mula server-side rendering papuntang asynchronous loading, o binalot ang element ng bagong container. Sa isang A/B test, puwede ring magkaiba ang structure ng parehong page para sa iba't ibang account.
Karaniwang sintomas ang hindi mahanap ang element, mapunta sa maling lugar ang click, o mapindot ang control na kapareho ang pangalan pero nasa ibang posisyon. Hindi network jitter ang ganitong failure, kaya hindi ito maaayos ng ilang retries.
Mas praktikal na bawasan ang pagdepende sa absolute paths. Unahin ang accessibility attributes, stable na business IDs, o relative relationships ng mga element; maghanda rin ng fallback selectors para sa parehong uri ng page para awtomatikong makalipat kapag pumalya ang primary selector. Kung may iframe o Shadow DOM ang page, kailangang lumipat muna sa tamang context, kung hindi ay tiyak na mabibigo ang paghanap.
Mali ang range ng paghihintay at timeout
Kung masyadong maikli ang paghihintay, maaaring ituring na failed ang element bago pa ito matapos mag-render, kaya parang may bug ang script. Kung masyadong mahaba, lumolobo ang oras ng isang task, bumababa ang throughput, at maaaring matakpan ng mahabang timeout ang tunay na error.
Mas maaasahan ang explicit waits kaysa sa fixed sleep: maghintay sa isang tiyak na kondisyon, gaya ng paglabas ng target element, pagbalik ng isang request, o pagkawala ng loading animation. Dapat layered ang timeout budget, na may hiwalay na limit para sa isang step, isang page, at buong task, at unti-unting hinihigpitan sa halip na iisang value ang gamitin sa lahat.
Mahalaga ring paghiwalayin ang paghihintay na maging usable ang page at ang paghihintay na mabuo ang business result. Sa una, kadalasang sapat ang paghintay na maging ready ang DOM; sa ikalawa, maaaring kailanganing hintayin ang API callback o pagbabago sa status text sa page. Kapag maling signal ang hinintay, maaaring magmukhang successful ang operation kahit hindi talaga naisulat ang data.
Nawawala ang progress sa gitna ng multi-step task
Ang registration, pag-order, at publishing ay madaling umabot sa mahigit sampung steps. Kapag huminto ang process sa gitna dahil sa timeout, browser crash, o host restart, at nasa memory lang ang state, sa susunod na run ay kailangang magsimula ulit mula sa umpisa o muling isumite ang nakaraang step.
Mas mahirap i-debug ang duplicate execution kaysa sa simpleng failure: dalawang beses tumatakbo ang parehong operation, nagkakaroon ng dagdag na record sa upstream system, at mahirap tukuyin kung saan ito nanggaling.
Ang solusyon ay magkaroon ng persistence point ang bawat step. Pagkatapos makumpleto ang bawat hakbang, isulat ang progress sa persistent storage kasama ang unique identifier ng task; pagkatapos ng restart, magpatuloy mula sa huling successful na punto. Hindi kailangan ng komplikadong framework—sapat na ang isang file o isang state record.
Ang pag-block ng environment ay mukhang code error
Nasa loob ng task ang unang tatlong klase ng problema, ngunit may isa pang nanggagaling sa environment. Maaaring pagsamahin ng site ang browser characteristics, access behavior, at network origin para tukuyin ang pinagmulan ng traffic. Kapag itinuring itong kahina-hinala, puwedeng magbalik ang site ng verification page, blankong content, o diretsong timeout. Sa task logs, halos kapareho ito ng execution error.
Karaniwang trigger ang mga sumusunod:
- Hindi tugma ang lokasyon ng egress IP, time zone, at language
- Lahat ng task ay nagpapadala ng requests mula sa iisang browser environment, kaya mas mataas nang malinaw ang request density kada unit of time kaysa sa totoong users
- Madalas magpalit ang environment, o paulit-ulit na nagla-login muli ang account
Apat na hakbang para itaas ang success rate
- Gawing idempotent ang bawat step. Bago tumakbo, tingnan muna kung natugunan na ang prerequisite para walang dagdag na side effect kapag inulit ang action. Natural na idempotent ang read operations; ang write operations ay kailangang protektahan ng unique identifier o deduplication key.
- I-classify ang failures. Ang temporary failures, gaya ng element na hindi pa rendered, network jitter, o API na nagbabalik ng 5xx, ay puwedeng i-retry gamit ang backoff. Ang deterministic failures, gaya ng restricted account, invalid parameters, o nawawalang target resource, ay hindi maaayos ng paulit-ulit na retry; markahan na itong terminated para hindi patuloy na kumain ng concurrency capacity.
- Regular na i-persist ang state. I-save ang progress, intermediate outputs, at kasalukuyang step para kapag nag-restart ang task ay magpatuloy ito kung saan huminto sa halip na bumalik sa unang step.
- I-isolate ang runtime environment bawat task. Bigyan ang bawat account o task ng sariling browser environment para hindi magbahagi ng Cookies at local storage, magkaroon ng makatuwirang pagkakaiba ang fingerprint characteristics, at tumugma ang time zone at language sa region ng egress IP.
Lalong mahalaga ang ikaapat na hakbang habang lumalaki ang scale ng mga task. Kapag dose-dosenang o daan-daang task ang sabay-sabay na tumatakbo, ang environment layer ang nagtatakda ng upper bound ng stability at ng lawak ng epekto kapag may problema. Sa ganitong scenario, nagbibigay ang PurpleMark ng kakayahang gumawa ng isolated environments on demand at mag-reclaim ng mga ito nang batch, kaya bawat account ay may sariling environment at hindi nagkakahaluan ang state ng mga task.
Ang nilalamang ito ay para lamang sa technical research at pagbabahagi ng development practices. Gamitin ang kaugnay na teknolohiya nang legal at alinsunod sa mga patakaran, at sundin ang terms of service ng target platform.
