yusufyildiz34 commented on issue #18163:
URL: https://github.com/apache/iceberg/issues/18163#issuecomment-6372027731

   I looked into this and it doesn't look intentional to me. When no snapshot 
is set, `RESTTableScan.planFiles()` sends no `snapshot-id`, so the server plans 
against whatever is current on its side, while the client has already resolved 
the schema and projection from the metadata it loaded. If a commit lands in 
between, the returned tasks come from a newer snapshot than the one the client 
resolved. Local planning avoids this because `snapshot()` falls back to 
`table().currentSnapshot()`, and the spec only describes `snapshot-id` as the 
snapshot for a point-in-time scan without saying what the server should use 
when it's absent. A small fix would be to send the client's current snapshot ID 
(keeping `use-snapshot-schema` false, as today) when neither a snapshot nor an 
incremental range is set, with a test that commits after creating the scan and 
checks that the planned files come from the client's snapshot. @singhpk234 does 
that match the intended behavior for server-side planning? If 
 so, I'd be happy to open a PR.
   


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