Add backfill conflicts documentation

[jmhsieh]

Summary

• Add new documentation page explaining how Geneva handles backfill conflicts
• Cover safe vs conflicting operations during backfill
• Document automatic retry behavior and recovery steps
• Add best practices for avoiding conflicts

Closes GEN-290

Test plan

• Run npx mintlify dev and verify new page renders correctly
• Check navigation shows "Conflicts" under Geneva > Job execution
• Verify links to related docs work

🤖 Generated with Claude Code

[prrao87]

Suggested change

	### Use INSERT-Only Operations During Backfill
	### Use Insert-Only Operations During Backfill

[prrao87]

Suggested change

	If you need to add data while a backfill is running, use INSERT-only operations:
	If you need to add data while a backfill is running, use insert-only operations:

[dantasse]

Looks good, thanks! Putting my AI engineer hat on, the worries that come to mind first are:

• running backfills on col1 and col2 simultaneously, we'll get the full results for both columns, right? (This doc answers this well I think)
• if another job deletes row 10, while my backfill tries to write to row 10, row 10 will still be gone, right? (I think this answers this well too)
• if a compaction or deletion occurs mid backfill, we won't write bad data, right? (e.g. writing the result for row 5 to row 4 because row 1 was deleted) - I don't think you explicitly say this. Which is probably fine because this is a pretty niche case that would be pretty weird if it did happen. But eh, brave new world of data lakes, I've seen weirder

So I think all the info you need is here; I might just add a sentence at the top emphasizing "backfills can't result in data loss, or writing incorrect data".

[jmhsieh]

Looks good, thanks! Putting my AI engineer hat on, the worries that come to mind first are:

• running backfills on col1 and col2 simultaneously, we'll get the full results for both columns, right? (This doc answers this well I think)

Yes

• if another job deletes row 10, while my backfill tries to write to row 10, row 10 will still be gone, right? (I think this answers this well too)

If it is just a delete and not concurrent, we may calculate the value and write it but the delete marker should override it. So a little extra compute but logically correct.

• if a compaction or deletion occurs mid backfill, we won't write bad data, right? (e.g. writing the result for row 5 to row 4 because row 1 was deleted) - I don't think you explicitly say this. Which is probably fine because this is a pretty niche case that would be pretty weird if it did happen. But eh, brave new world of data lakes, I've seen weirder

if a compaction or delete happens mid backfill, we won't write bad data. We'll fail the fragment, partially complete the job, and require a subsequent backfill call will recalculate the values that were null. (assumed not completed, committed before the compaction). I think that's documented, will double check.

So I think all the info you need is here; I might just add a sentence at the top emphasizing "backfills can't result in data loss, or writing incorrect data".

yeah, I'll add that. conflict with compactions could result in partial commits that should only do small amount of recalculation. (note: there are further optmizations we could do, but it gets quite complicated, so we punted).

[jmhsieh]

I think that concern is covered with this caveat, going to commit