One table sync keeps failing

Occam’s razor - you deleted/renamed something you shouldn’t have, resulting in an impossible or dizzyingly loopy schema. Or someone with access to your base did. I’d suggest making a backup, restoring your base to an earlier version which you are certain allowed the use case you’re describing, and compare the two, property by property.

We can speculate here as much as we want but oddities such as this one are a large part of the reason backups exist in the first place; troubleshooting them manually, as you have hopefully realized by now, is a highway to looney land. :grinning_face_with_sweat:

When this happened to me, here is how I solved the problem (mostly):

1. Enable selective sync in the target base
2. Disable all but the primary field. :white_check_mark: success
3. Enable some fields. :white_check_mark: success
4. Enable some more until … :negative_squared_cross_mark: failure
5. Disable one at a time to isolate the offender. :white_check_mark: success
6. Remove offender from view in source base, and re-enable sync of all fields in the target base. :white_check_mark: success
7. Create new copy of field—it was a rollup field—in source base. :negative_squared_cross_mark: failure
8. (a) Create new copy of underlying linked field in source base, (b) add a test value in the linked field, (c) redirect rollup to new linked field. :white_check_mark: success
9. Paste data from old linked field into new linked field. :white_check_mark: success
10. Update new field names to original values (hoping for success but expecting failure). :negative_squared_cross_mark: failure
11. Back to step 8, but using the same rollup field. :negative_squared_cross_mark: failure

It looks like starting over at step 7 might work, but I stopped here for now.