singhpk234 commented on code in PR #14767:
URL: https://github.com/apache/iceberg/pull/14767#discussion_r2677940782
##########
core/src/main/java/org/apache/iceberg/rest/RESTTableScan.java:
##########
@@ -151,6 +175,21 @@ private CloseableIterable<FileScanTask>
planTableScan(PlanTableScanRequest planT
this.planId = response.planId();
PlanStatus planStatus = response.planStatus();
+ List<Credential> storageCredentials = response.credentials();
Review Comment:
> I think what matters to a server is to know in what context the
credentials were initially vended
This where i believe there is a little bit of disconnect from my end, i
think we didn't say in the spec that creds are vended for this plan-id or
scoped down to this plan-id, infact we just say they are storage creds. One
concrete use case i can think of is
see by default catalog vends creds for 2 hours so if the server wants to
clean up resources (let say it cached stuff) of the plan post 2 hours it can do
that but if the client comes back to catalog post 2 hours for the credential
call and doesn't present the context it has i,e the plan-id server has no clue
of when to release resource. Here if the plan-id is send it would be a signal
to the server that hey keep the resource of plan for 2 more hour kind of a ttl
mechanism. Hence i am suggesting if we have plan-id let pass the plan-id to the
server, we never know what more use cases we can unlock.
I understand in the spec its not mandatory to send the plan-id but if
present i would suggest we should as we don't define when should we plan-id.
Please let me know you thoughts considering above.
--
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]
