> ## Documentation Index
> Fetch the complete documentation index at: https://support.detrics.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Resync & Recovery

> Re-fetch data, recover from errors, and manage historical backfills

<Info>**Last updated:** March 18, 2026</Info>

## When to Resync

A resync re-fetches data from the platform, useful when:

* You **added new fields** to a table and want historical data for those fields
* You **changed filters** and want historical data with the new filter criteria
* You **changed platform options** (e.g., attribution windows) and want consistent historical data
* You suspect **data quality issues** and want a clean reload
* A platform had an **API outage** during a sync and data is incomplete

## Resync Options

Detrics offers two resync modes:

### Resync (Retain Data)

Re-fetches data based on each table's historical sync range **without deleting** existing data outside that range.

* For **Incremental** tables: Deletes and re-inserts within the refresh window (same as a normal sync, but triggers a broader re-fetch)
* For **Full Refresh** tables: Replaces the table with fresh data (same as a normal sync)
* For **Full Append** tables: Appends a new complete snapshot

**Best for:** Adding new fields, fixing recent data quality issues, or recovering from partial sync failures.

### Resync (Remove Data)

**Deletes all existing data** for the transfer's accounts, then re-fetches everything from scratch based on each table's historical sync range.

* All rows with matching `_detrics_account_id` values are deleted first
* Then a full historical sync is performed

**Best for:** Complete data reload after major configuration changes, switching sync modes, or when you want a guaranteed clean slate.

<Warning>
  Resync (Remove Data) permanently deletes existing rows from your BigQuery tables. Make sure you understand the implications before using this option. The deleted data cannot be recovered from Detrics (though BigQuery's time travel feature may let you recover it within 7 days).
</Warning>

## How to Trigger a Resync

### Full Transfer Resync

1. Go to the transfer's detail page
2. Click the **Resync** button
3. Choose **Retain Data** or **Remove Data**
4. Confirm the action

The resync starts immediately and runs as a special transfer run (visible in run history with the "Resync" run type).

### Single Table Resync

If only one table needs re-fetching:

1. Go to the transfer's detail page
2. Navigate to the **Tables** tab
3. Click on the table you want to resync
4. Click **Resync This Table**

This re-fetches data only for the selected table, leaving other tables untouched. Useful when you've modified a single table's configuration.

## Recovery from Errors

### Connection Errors (Expired Token)

If a transfer fails because the platform token expired:

1. Go to [**Workspace → Connections**](https://app.detrics.io/datasources) and reconnect the platform
2. Go back to the transfer and click **Resume** (if auto-paused)
3. The next scheduled sync will use the refreshed token

No resync is needed, the normal schedule will catch up automatically (incremental tables re-fetch the refresh window, which covers the gap).

### BigQuery Permission Errors

If a transfer fails because BigQuery permissions were revoked:

1. Re-grant the Detrics service account the **BigQuery User** role
2. Test the connection on the destination page
3. Resume the transfer

### Partial Success

If a run completes with **Partial Success** (some tables succeeded, some failed):

* Successful tables have their data loaded normally
* Failed tables retain their previous data, nothing is lost
* Check the per-table error details in the run history
* Fix the issue and either wait for the next scheduled sync or trigger a manual sync

### Interrupted Syncs

If a sync is interrupted (timeout, transient error):

* **Completed chunks** are preserved, their data is already in BigQuery
* **Incomplete chunks** will be retried on the next sync
* For Incremental tables, the refresh window naturally covers recent data
* For large initial syncs, consider triggering a manual resync if significant chunks were missed

## Best Practices

* **Start with Retain Data**: Most resync needs are handled without deleting existing data
* **Use Single Table Resync** when only one table's configuration changed
* **Check run history** after a resync to verify the expected row counts
* **Time your resyncs**: Large resyncs consume platform API quota. Run them during off-peak hours when other syncs aren't scheduled