FBScrapingWarningMutation

Seen 4 time(s) in 4 run(s).

What it sent and what came back (the newest 1 from our runs)

Read from each run's own recording (rule 73), secrets and signed link tokens taken out. Kept in ~/.logCli/rea/clientFacts.json, so it stays after the run is pruned.

runs/host/20261026T164654_61594285317994, step 18: clickRole button "…": 200, 731 ms

Sent:

{
  "fb_api_caller_class": "RelayModern",
  "fb_api_req_friendly_name": "FBScrapingWarningMutation",
  "server_timestamps": "true",
  "variables": {},
  "doc_id": "24406519995698862"
}

Answered:

{
  "data": {
    "fb_scraping_warning_clear": {
      "success": true
    }
  },
  "extensions": {
    "server_metadata": {
      "request_start_time_ms": 1793033458851,
      "time_at_flush_ms": 1793033459436
    },
    "is_final": true
  }
}

What it does

Clears Facebook's scraping warning on the account (fb_scraping_warning_clear). It fires about 530 ms after the "We suspect automated behaviour on your account" page is dismissed: dismissing that page is this request. So Facebook had flagged the account as scraping before the page was shown.

What our machine does with it

The connect machine's automatedBehaviour page kind dismisses the warning (Listaro's path, rule 23), which sends this. The machine reads the page, not this response; the next page read decides where it goes.

What can go wrong

Seen only on Philadelphia, the account later sent to a video selfie. A scraping flag is the earliest sign in our recordings that Facebook distrusted it, so any run that meets this should be read back (rule 25) before the account runs again. No error seen yet; a non-200 would mean the warning stayed and the next page is likely a checkpoint.