Scraper API: send waitFor as an object, read the target status from http_code

[jehrr]

Two defects in scraper_api_client.py

Measured 2026-09-23 against https://scraper.2captcha.com/tasks/sync:

1. waitFor sent as a JSON-encoded string (what _build_wait_for returned) is answered HTTP 422 ScrapeParser: params.waitFor must be an object — and the call is still billed ($0.0005). The same request with an object answers 200. So every run with --wait-text / --wait-element / --wait-state failed with exit 5 and cost money. _build_wait_for now returns a dict (logged through json.dumps), and the docstring that said the API wanted a double-encoded string now says what was measured.
2. The target status was read from status, which is the API's own verdict string ("success"). The target site's HTTP code is http_code. The client handed "success" onward, so a target 403/503 never reached the page classifier. It now reads http_code (int), falling back to status only if that is itself an int.

Regression check

test_scraper_api_sends_waitfor_as_an_object_and_reads_http_code in smoke_test.py: drives the real function with requests.post stubbed (no network), returning {"status":"success","http_code":403,"body":"<html></html>"}, and asserts (a) the payload's waitFor is a dict and (b) the status handed onward is 403 (int).

Control: (registered with ok &= … in main(), this suite's shape) with origin/main's scraper_api_client.py swapped into this branch's tree (file hash confirmed changed), the suite went red with exactly 2 failures, both this check's messages (waitFor came back as the string '{"text": "mug"}', status as 'success'). Restored: smoke_test: OK.

Live result

One call, key from the environment: scraper_api_client.py --url 'https://www.etsy.com/search?q=handmade+mug' --wait-text mug, no --cdp-url → API answered HTTP 408 {"error":"timeout","status":"pending"} after 60 s (the default --timeout), exit 5. So the object-form waitFor was accepted (no 422), but that call produced no target status to log — the http_code half is verified offline only for this repo. Not retried: one paid call per repo.

Not changed

The three browser engines, product_parser.py, the page classifier and the default --timeout are untouched. No version bump — the CHANGELOG entry is under [Unreleased]. Reference fix: zimmo-scraper PR #1.

🤖 Generated with Claude Code

[jehrr]

Second live call on this branch (2026-09-23, --timeout 120, --url 'https://www.etsy.com/search?q=handmade+mug' --wait-text mug): API accepted the object waitFor (no 422) and answered HTTP 408 {"error":"timeout","status":"pending"} after 120 s. So the payload fix is live-verified; the http_code half is verified offline only, because this site's page did not finish inside the API's sync window on either call. Not a regression: the unfixed client would have got a billed 422 before reaching the site.