[source-facebook-marketing] Skip Inaccessible Accounts Instead of Failing Entire Sync

[vai-airbyte]

Problem Summary:
When we configure the Facebook Marketing connector to pull data from a list of multiple account_ids, the entire sync job fails if we lose access permission to just one of the accounts in that list. Instead of skipping the account with the error and proceeding with the others, the entire job is aborted.

Context and Impact:
We are a digital marketing agency that manages dozens of client accounts. It is common for clients to come and go, which means our access to their Facebook Ads accounts is frequently granted and revoked.

Due to the connector's current behavior, whenever a client relationship ends and we lose access, our data pipeline for all other clients stops working. This requires a team member to manually edit the account_ids list in the connector's configuration to remove the problematic account.

This causes:

• Data Collection Disruptions: Delays in data availability for analysis and reporting across all our active clients.
• Operational Overhead: The need for constant manual intervention, which is inefficient and error-prone.
• Lack of Resilience: The data pipeline is very fragile, as a single point of failure affects the entire ecosystem.

Current Behavior (What Happens Now):

1. The Facebook Marketing source is configured with a list of account_ids: [account_A, account_B, account_C].
2. We have valid permissions for accounts A, B, and C, and the sync runs perfectly.
3. We lose access to account_C.
4. On the next scheduled run, Airbyte attempts to access account_C, encounters a permission error, and fails the entire job.

Result: No data is synced, not even for account_A and account_B, for which we still have valid permissions.

Expected Behavior (What Should Happen):

1. The Facebook Marketing source is configured with the same list: [account_A, account_B, account_C].
2. We lose access to account_C.
3. On the next run, Airbyte:
   a. Attempts to sync account_C and encounters a permission error.
   b. Logs a clear WARNING or ERROR in the logs, stating that account_C was skipped due to a permission error (e.g., "Skipping account_id 'account_C' due to permission error.").
   c. Continues the process and successfully syncs the data for account_A and account_B.

Result: The job finishes successfully (or with a "partial success" status), and the data from the valid accounts is imported into our destination (BigQuery), ensuring service continuity for our other clients.