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 didn't say 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 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]
