Utilizzo di Routing Keys e Profile Leases nelle code di worker di Playwright
Un errore di Playwright come TimeoutError: page.click failed è spesso una bugia.
L'errore ti dice cosa ha visto lo script. Non ti dice perché lo script si trovasse nel posto sbagliato fin dall'inizio.
Una volta ho visto due worker prelevare job per lo stesso account. Entrambi i worker hanno aperto lo stesso profilo browser contemporaneamente. Un worker era in attesa su una pagina lenta. L'altro worker ha riprovato, ha cambiato lo stato della sessione e ha causato un fallimento.
Il problema non era il codice. Il problema era la coda.
La maggior parte delle code di worker è progettata per job stateless.
- Prendi un job.
- Trova un worker libero.
- Esegui il task.
- Segnalalo come completato.
Questo funziona per screenshot o chiamate API. Fallisce per l'automazione del browser.
Un profilo browser non è stateless. Appartiene a un account, un proxy e uno stato della sessione. Il worker più veloce non è sempre il worker giusto.
Per scalare in modo sicuro, devi cambiare la tua logica.
Invece di chiedere: Quale worker è libero?
Chiedi: Quale ambiente dell'account è sicuro da usare ora?
Puoi risolvere questo problema con tre livelli:
Routing Keys Non permettere a un qualsiasi worker di prelevare un qualsiasi job. Usa una routing key basata sul profile ID o sull'account ID. Questo garantisce che un solo worker tocchi un profilo specifico alla volta.
Profile Leases Un "queue claim" significa che un worker possiede un job. Un "profile lease" significa che un worker ha il permesso di utilizzare un profilo browser specifico per un tempo prestabilito. Usa un lease con un heartbeat. Se il task richiede più tempo del previsto, il worker deve rinnovare il lease.
Fencing Tokens I worker obsoleti sono pericolosi. Se un worker perde il suo lease a causa di un ritardo di rete ma continua a girare, potrebbe tentare di scrivere dati. Usa un fencing token. Lo strato di storage dovrebbe rifiutare qualsiasi scrittura proveniente da un vecchio token.
Devi anche aggiungere un readiness gate. Prima di avviare Playwright, controlla questi elementi:
- L'account è in pausa?
- Il profilo richiede una revisione umana?
- La regione del proxy corrisponde ai requisiti del job?
Un job bloccato non è sempre un job fallito. Spesso è solo un job in attesa del contesto giusto.
Smetti di costruire code che diano priorità solo alla velocità. Costruisci code che diano priorità allo stato dell'account.
Fonte: https://dev.to/web4browser/using-routing-keys-and-profile-leases-in-playwright-worker-queues-a53