# Changelog of Computrabajo Job Listings Scraper — Argentina & LatAm Salaries (`mfapitools/computrabajo-jobs-scraper`) Actor

- **URL**: https://apify.com/mfapitools/computrabajo-jobs-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/mfapitools/computrabajo-jobs-scraper.md

## Changelog

All notable changes to this actor will be documented here.

Format: `YYYY-MM-DD | version | description | author`

***

2026-07-25 | 0.1.10 | PENDING OWNER REVIEW (not yet deployed — committed on branch `fix/computrabajo-completeness`). Replaced the `RequestList` + dynamic `crawler.addRequests()` mix (flagged by crawlee's own warning every run) with a single explicit `RequestQueue` via `crawler.run([{url: startUrl, ...}])`, per crawlee's documented pattern — eliminates the `RequestManagerTandem` code path entirely, removing a theoretical eventual-consistency race where the Apify platform's `RequestQueue.isFinished()` can flip true before a just-enqueued batch of detail requests (added inside the last list-page handler) is visible to the queue head. IMPORTANT — re-measurement finding: the specific "40 enumerated / 30 executed, ~25% silent loss" claim from the prior validation-agent entry below does NOT reproduce. New instrumentation (logs enumerated-vs-executed counts every run) shows the "20 jobs on page 1" + "20 jobs on page 2" = 40 raw listings include ~10 genuine duplicate job URLs that Computrabajo's own pagination returns on both pages (verified: `listItemsByUrl` — a plain URL-keyed Map — collapses 40 raw list-card parses down to 30 unique URLs, and all 30 were fetched and pushed, both in the OLD code's baseline run `2hUT4h64FBaXjmz2F` and across 3 fresh runs on the fixed code). Stress-tested with `maxItems:0` (unlimited, 13 result pages, 260 unique detail URLs): 251 pushed + 9 detail-request failures (real 403s from Computrabajo's bot protection under sustained pagination load, individually logged) + 0 silently dropped — enumerated count and accounted-for count (pushed+quarantined+failed) matched exactly. So: the RequestList/RequestQueue refactor is kept as a legitimate defensive fix (removes a real, crawlee-documented anti-pattern and its theoretical platform race), but it should NOT be described as fixing a confirmed 25%-data-loss bug — that specific loss was never observed to occur; the original diagnosis conflated cross-page URL de-duplication with request drops. Added `src/completeness.ts` (`checkCompleteness`, unit-tested) + wiring in `src/crawl.ts`: if items produced ever fall materially short of URLs enumerated for any unaccounted reason, a loud `console.error` "COMPLETENESS WARNING" fires with both numbers — makes any future silent-loss regression observable in the log instead of passing as a quiet SUCCEEDED run. Extracted crawl orchestration from `main.ts` into `src/crawl.ts` so it's testable without a live `Actor.init()`; output schema/field names unchanged (drop-in for existing consumers). 12 new tests (7 unit tests on `checkCompleteness`, 3 integration tests against a local HTTP fixture server reproducing the real 2-page/40-URL/10-overlap shape, all green: 85/85 total, `tsc --noEmit` clean). Verified on a temporary private actor (`computrabajo-completeness-fix-verify`, id `I2TExLCjd4yLagGhe`, deleted after verification) with 4 live runs against the real site — see LOG.md for full run ids and counts. Published actor `computrabajo-jobs-scraper` was NOT touched (no `apify push` run against it; only read-only runs for baseline measurement, which self-runs bill zero events). | Claude Sonnet (builder agent)
2026-07-25 | 0.1.9 | Live-validation fix: `@money/shared`'s `buildProxyConfig()` requested a proxy group named `'DATACENTER'`, which doesn't exist on this account (real group: `BUYPROXIES94952`) — every run silently fell back to no proxy. Fixed group name in shared lib, but that alone made things *worse* here: routing default (non-residential) runs through the now-working shared datacenter proxy pool introduced 403s from Computrabajo's bot protection that a direct connection never hit (verified: run `lf3N6JSLpnlHQQWbe`, 4 blocked requests with the datacenter proxy vs 0 with none, same search). So computrabajo now deliberately requests NO proxy at all for the default case — only escalates to residential when `useResidentialProxy: true` — matching the actor's own documented "works from plain IPs" behavior. Re-verified clean (run `gaeVSEwubyqJplAyK`: 30/30 jobs, 0 failed requests, no proxy warning). Separately noted but NOT fixed (structural, needs a live-target-tested refactor): a `RequestList`/dynamic-`RequestQueue` mixing anti-pattern (crawlee warns about it every run) appears to silently drop ~20% of enqueued detail-page requests once pagination is involved — default run returns 30 jobs though ~40 were listed across 2 result pages; no crash, no quarantine, just fewer jobs than available. | Claude Sonnet (live-validation agent)
2026-07-24 | 0.1.1 | Optional `enrichCompany` input (default false, output/cost unchanged when off): adds `companyDetails` (industry, logo, verified badge, rating, review/follower/job counts) sourced from job-page JSON-LD (free) + one cached fetch per distinct company's profile page; no company-size/sector field exists publicly so none is fabricated; 22 new tests on live-captured fixtures | builder-agent
2026-07-23 | 0.1.0 | Initial implementation — Computrabajo scraper (19 countries, SSR HTML), Bumeran stub with parsers and URL builders; unit tests with live HTML fixtures | builder-agent