Playwright Worker Queues-இல் Routing Keys மற்றும் Profile Leases-ஐப் பயன்படுத்துதல்

TimeoutError: page.click failed போன்ற Playwright பிழைகள் பெரும்பாலும் தவறான தகவலையே தருகின்றன.

அந்தப் பிழை ஸ்கிரிப்ட் எதைப் பார்த்தது என்பதை மட்டுமே சொல்கிறது. ஸ்கிரிப்ட் ஏன் தொடக்கத்திலேயே தவறான இடத்தில் இருந்தது என்பதற்கான காரணத்தை அது சொல்லாது.

ஒரே கணக்கிற்கான (account) வேலைகளை (jobs) இரண்டு workers எடுத்ததைக் கண்டேன். இரண்டு workers-உமே ஒரே நேரத்தில் ஒரே browser profile-ஐத் திறந்தனர். ஒரு worker மெதுவான பக்கத்திற்காகக் காத்திருந்தது. மற்றொரு worker மீண்டும் முயற்சி செய்து, session state-ஐ மாற்றியதால் தோல்வி ஏற்பட்டது.

பிரச்சனை குறியீட்டில் (code) இல்லை. பிரச்சனை queue-வில் தான் இருந்தது.

பெரும்பாலான worker queues stateless jobs-காகவே வடிவமைக்கப்பட்டுள்ளன.

  • ஒரு வேலையை எடுத்தல்.
  • ஒரு காலியான worker-ஐக் கண்டறிதல்.
  • பணியைச் செய்தல்.
  • முடிந்தது எனப் பதிவு செய்தல்.

இது screenshots அல்லது API calls-களுக்குச் சரியாக இருக்கும். ஆனால் browser automation-க்கு இது தோல்வியடையும்.

ஒரு browser profile என்பது stateless கிடையாது. அது ஒரு குறிப்பிட்ட account, proxy மற்றும் session state-ஐச் சார்ந்தது. மிக வேகமான worker எப்போதும் சரியான worker என்று சொல்ல முடியாது.

பாதுகாப்பாகப் பெரிய அளவில் (scale) செயல்பட, உங்கள் தர்க்கத்தை (logic) மாற்ற வேண்டும்.

"எந்த worker காலியாக உள்ளது?" என்று கேட்பதற்குப் பதிலாக, "தற்போது எந்த account environment-ஐப் பயன்படுத்துவது பாதுகாப்பானது?" என்று கேளுங்கள்.

இதை மூன்று அடுக்குகளின் (layers) மூலம் தீர்க்கலாம்:

  1. Routing Keys எந்த ஒரு worker-உம் எந்த வேலையையும் எடுத்துக்கொள்ள அனுமதிக்காதீர்கள். Profile ID அல்லது account ID-ஐ அடிப்படையாகக் கொண்ட routing key-ஐப் பயன்படுத்துங்கள். இது ஒரு குறிப்பிட்ட profile-ஐ ஒரே நேரத்தில் ஒரு worker மட்டுமே கையாளப்படுவதை உறுதி செய்யும்.

  2. Profile Leases ஒரு queue claim என்பது ஒரு worker ஒரு வேலையைத் தன்வசம் வைத்திருப்பதைச் சொல்கிறது. ஒரு profile lease என்பது ஒரு குறிப்பிட்ட காலத்திற்கு ஒரு குறிப்பிட்ட browser profile-ஐப் பயன்படுத்த ஒரு worker-க்கு அனுமதி அளிப்பதைக் குறிக்கிறது. Heartbeat வசதியுடன் கூடிய lease-ஐப் பயன்படுத்துங்கள். பணி எதிர்பார்த்ததை விட அதிக நேரம் எடுத்தால், அந்த worker lease-ஐப் புதுப்பிக்க வேண்டும்.

  3. Fencing Tokens காலாவதியான (Stale) workers ஆபத்தானவை. நெட்வொர்க் தாமதத்தினால் (network lag) ஒரு worker தனது lease-ஐ இழந்தாலும், அது தொடர்ந்து இயங்கிக்கொண்டிருந்தால், அது தரவுகளை எழுத முயற்சி செய்யலாம். இதற்காக fencing token-ஐப் பயன்படுத்துங்கள். பழைய token மூலம் வரும் எந்தவொரு write செயல்பாட்டையும் storage layer நிராகரிக்க வேண்டும்.

நீங்கள் ஒரு readiness gate-ஐயும் சேர்க்க வேண்டும். Playwright-ஐத் தொடங்குவதற்கு முன், இவற்றைச் சரிபார்க்கவும்:

  • கணக்கு (account) நிறுத்தப்பட்டுள்ளதா?
  • Profile-க்கு மனிதத் தலையீடு (human review) தேவையா?
  • Proxy பகுதி வேலையின் தேவைகளுடன் ஒத்துப்போகிறதா?

தடுக்கப்பட்ட (blocked) ஒரு பணி எப்போதும் தோல்வியடைந்த பணி அல்ல. அது பெரும்பாலும் சரியான சூழலுக்காக (context) காத்திருக்கும் ஒரு பணி மட்டுமே.

வேகத்திற்கு மட்டும் முன்னுரிமை அளிக்கும் queues-களை உருவாக்குவதை நிறுத்துங்கள். Account state-க்கு முன்னுரிமை அளிக்கும் queues-களை உருவாக்குங்கள்.

ஆதாரம்: https://dev.to/web4browser/using-routing-keys-and-profile-leases-in-playwright-worker-queues-a53