[ https://issues.apache.org/jira/browse/KUDU-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915909#comment-17915909 ]
Alexey Serbin commented on KUDU-3639: ------------------------------------- {quote} Since the REST API context doesn't have an RpcContext, I propose using a default value for the client deadline. Specifically, we can use MonoTime::Max() as the default, which represents no specific client deadline and aligns with the behavior when the client does not explicitly set one. {quote} Sure, that will do for the initial version. I guess we could introduce extra parameters for HTTP-based RPCs as well later on using HTTP headers or extra query parameters, but at this point it's not a requirement to have such provisions, IIUC. Overall, that approach looks OK to me, but please take a closer look at the code to make sure there aren't any surprises. I'd think of checking out what else is necessary to pass along from the RpcContext for all the methods you are planning to update. Thank you! > Implement {Delete/Alter/Create}Table Functions Without RpcContext > ----------------------------------------------------------------- > > Key: KUDU-3639 > URL: https://issues.apache.org/jira/browse/KUDU-3639 > Project: Kudu > Issue Type: New Feature > Reporter: Gabriella Lotz > Assignee: Gabriella Lotz > Priority: Major > > The CatalogManager::\{DeleteTableRpc, CreateTable, AlterTableRpc} functions > currently rely on rpc::RpcContext to extract the username of the requestor > for authorization. However, in the REST catalog API implementation, > RpcContext is not used, and only the username is directly available. > To support REST API functionality, new functions are required that replace > RpcContext with an explicitly provided username while maintaining the same > core logic for table operations. > Requirements: > * Create new functions: > ** CatalogManager::DeleteTableWithUser > ** CatalogManager::AlterTableWithUser > ** CatalogManager::CreateTableWithUser > * These functions should: > ** Accept a username parameter instead of rpc::RpcContext. > ** Implement the same authorization, logging, and HMS integration logic as > their corresponding RPC versions (DeleteTableRpc, AlterTableRpc, and > CreateTable). > ** Refactor shared logic between the existing RPC functions and the new > \{Delete/Alter/Create}TableWithUser functions into reusable helper functions > to minimize code duplication. -- This message was sent by Atlassian Jira (v8.20.10#820010)