Resync & Recovery

​

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.

​

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 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