Uh oh!
There was an error while loading. Please reload this page.
feat(scrapper): implementar concorrência por provider - #231
Conversation
hltav
left a comment
There was a problem hiding this comment.
A implementação principal está bem estruturada e segue corretamente a direção da PAV-120: orçamento global e por provider, scheduler round-robin, fila limitada, backpressure, capacidades explícitas e remoção da concorrência interna dos adapters.
Antes do merge, precisamos concluir os critérios ainda não demonstrados:
aguardar explicitamente o produtor;
classificar corretamente cancelamentos com causa customizada;
preservar uma amostra estruturada dos erros e registrar limites efetivos;
completar os testes de cancelamento, liberação, lote e encerramento de goroutines;
estabilizar a suíte completa com race detector;
remover o comentário obsoleto do Adzuna.
Depois dessas correções e da execução bem-sucedida de go test ./... e go test -race ./..., a PR fica pronta para aprovação e merge, sem deixar esses pontos como débito técnico.
##Cobertura de Testes
A cobertura adicionada é boa, mas ainda faltam demonstrações explícitas de alguns critérios de aceite da PAV-120. Antes do merge, por favor, adicionar testes para:
limite global 1 executando múltiplas tarefas estritamente de forma sequencial;
permissões liberadas depois de sucesso, erro do adapter e cancelamento durante execução;
produtor e workers encerrados após sucesso, erro e cancelamento;
cancelamento enquanto o produtor está bloqueado por backpressure;
ausência de tarefas iniciadas depois do cancelamento;
cancelamento durante requisição HTTP em andamento;
cancelamento durante espera de retry;
cancelamento durante paginação;
limite do lote/slot respeitado por providers batch;
encerramento sem vazamento de goroutines.
A validação de goroutines pode ser feita com goleak ou por sincronização determinística com canais/WaitGroups, desde que o teste comprove que todas as goroutines criadas pela execução terminaram antes do retorno.
| runStats.recordCompleted(task, err, time.Since(started)) | ||
| metrics.ScrapeRunsTotal.WithLabelValues(source).Inc() | ||
| if err != nil { |
There was a problem hiding this comment.
Precisamos preservar informações operacionais sobre a falha da tarefa. Atualmente o erro é contabilizado na métrica e no resumo agregado, mas seu conteúdo e a instância concreta do adapter são descartados. Com isso, o summary pode informar errors > 0, porém não permite identificar qual erro ocorreu nem qual fonte/instância falhou, especialmente em providers com vários adapters, como Greenhouse e Lever.
Antes do merge, por favor, registre uma amostra estruturada do erro por provider, incluindo pelo menos provider, source (task.adapter.SourceName()), mode e error. Isso pode ser incorporado ao resumo agregado para evitar um log por tarefa e não aumentar excessivamente a cardinalidade.
Aproveitar o mesmo summary para informar também o max_concurrency_effective do provider, pois o override registrado pode ser maior que o limite efetivo quando a requisição reduz a concorrência global.
Essa correção é necessária para atender aos critérios da PAV-120 de identificar provider e tarefa nos erros, registrar erros/timeouts por provider e informar o comportamento efetivo do pipeline.
| break schedule | ||
| } | ||
| go produceTasks(ctx, tasks, adapterList, req.Keywords, runStats) |
There was a problem hiding this comment.
O produtor é iniciado em uma goroutine, mas não faz parte do WaitGroup. Atualmente aguardamos somente os workers antes de fechar results e retornar. Em caso de cancelamento, o produtor tende a encerrar ao observar o contexto, mas não existe garantia explícita de que ele terminou antes do retorno de runWithConcurrency.
A PAV-120 exige encerramento de produtores e workers, ausência de goroutines abandonadas e espera de todas as goroutines antes do retorno. Por favor, inclua o produtor no mecanismo de sincronização — via WaitGroup, producerDone ou errgroup — garantindo que ele tenha terminado antes de a execução retornar.
Adicionar também um teste que cancele a execução enquanto a fila estiver cheia e comprove que:
o produtor termina;
os workers terminam;
nenhuma nova tarefa começa após o cancelamento;
Run retorna somente depois do encerramento dessas goroutines.
| s.summary(task).Produced++ | ||
| } | ||
| func (s *providerRunStats) recordCompleted(task adapterTask, err error, duration time.Duration) { |
There was a problem hiding this comment.
A classificação considera cancelamento apenas quando err é compatível com context.Canceled. Quando a execução é cancelada com uma causa customizada, como runlock.ErrLost, o adapter pode retornar essa causa e o summary contabiliza a tarefa como erro comum, não como cancelamento.
Isso torna incorretos os logs operacionais justamente no cenário de perda do lock distribuído, que é um critério explícito da PAV-120.
Por favor, faça recordCompleted receber ou considerar o estado/cause do contexto e diferencie:
cancelamento comum;
deadline/timeout;
perda do lock;
erro real do provider.
Adicionar teste com context.WithCancelCause usando uma causa customizada e confirmar que a tarefa é contabilizada como cancelada e que o motivo do encerramento é preservado.
hltav
commented
Aug 28, 2026
Os três pontos levantados no review foram atendidos de forma satisfatória. A implementação agora aguarda produtor e workers, possui cobertura de lifecycle com goleak, classifica causas customizadas e registra erros estruturados com limite efetivo por provider. Restou apenas uma melhoria não bloqueante na precedência de context.Cause(ctx) em outcomeReason, que pode fazer o summary registrar context canceled em vez da causa específica da perda do lock. Como isso não altera o comportamento funcional do pipeline, será registrado como débito técnico. Testes, race detector e CI passaram. Aprovado. |
Uh oh!
There was an error while loading. Please reload this page.
Card
O que foi feito
scraper-gocom dois tetos: global (SCRAPER_MAX_CONCURRENCY, padrão12) e por provider (SCRAPER_PROVIDER_MAX_CONCURRENCY, padrão2), com overrides opcionais emSCRAPER_PROVIDER_CONCURRENCY_OVERRIDESno formatoprovider=limite. Config inválida, vazia, duplicada, desconhecida ou acima do teto global impede a inicialização.adapters × keywordspor um scheduler round-robin com fila limitada (maxConcurrency * 2) e workers fixos. O orçamento é cancelável, o release é idempotente e o limite efetivo émin(provider, global). Providers com várias instâncias (Greenhouse/Lever) compartilham o mesmo limite.linkedin,adzuna,themuse,gupy,inhire,jooble,greenhouse,lever) e modosbatch(LinkedIn, Adzuna, Jooble, Gupy),catalog(The Muse, InHire, Greenhouse, Lever) ekeywordpara fontes ainda não migradas. Catálogos são buscados uma vez e agregam keywords, sem duplicar jobs.INHIRE_DETAILS_CONCURRENCYfoi removida. Logs agregados:scraper concurrency budgetno início da run escraper provider execution summarypor provider. A fórmula da cache key permanece inalterada.Validação
go test ./...emscraper-gogo test -race ./...emscraper-go.env.example,docker-compose.ymleSCRAPER.mdcomSCRAPER_PROVIDER_MAX_CONCURRENCY=2eSCRAPER_PROVIDER_CONCURRENCY_OVERRIDES=""INHIRE_DETAILS_CONCURRENCYnão aparece mais em env/Compose/docs0, acima do global) e confirmar fail-fast na inicialização