tanmayrauth opened a new issue, #1166:
URL: https://github.com/apache/iceberg-go/issues/1166

   ### Feature Request / Improvement
   
   `iceberg rollback` (added in #1071) currently requires `--snapshot-id`. In 
practice, when you're rolling back during an incident, you usually know the  
time — "before the bad job at 03:00 UTC" — not the snapshot ID. Looking it up 
via `iceberg snapshots` first is an extra step you'd rather skip while paged.
   
     Both PyIceberg (`rollback_to_timestamp`) and Spark Iceberg (its 
`rollback_to_timestamp` procedure) support this, so it's mostly catching up on 
parity.
   
     Proposed:
   
         iceberg rollback <table-id> --timestamp 2026-01-15T03:00:00Z [--yes]
   
     `--snapshot-id` and `--timestamp` would be mutually exclusive, exactly one 
required.
   
     The change should stay in `cmd/iceberg/upgrade_rollback.go`. The snapshot 
list is already chronological — `MetadataBuilder.AddSnapshot` enforces that in 
`table/metadata.go` — so resolving the timestamp is a linear scan from the end. 
The resolved ID then feeds into the existing `RollbackToSnapshot` path in 
`table/transaction.go`, which already handles the ancestry check and the 
`AssertRefSnapshotID` guard, so no library-level changes are needed.
   
     If no snapshot satisfies `TimestampMs <= t`, the command should error out 
clearly rather than rolling back to nothing.
   
   @zeroshade  @laskoviymishka  this can be a good-first-issue


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to