[PECOBLR-435] added application name to track BiTool#837
Conversation
samikshya-db
left a comment
There was a problem hiding this comment.
Minor comments, LGTM otherwise. Thanks for this!
| DatabricksConnectionContextFactory.create(url, info); | ||
| DriverUtil.setUpLogging(connectionContext); | ||
| UserAgentManager.setUserAgent(connectionContext); | ||
| updateClientAppName(connectionContext.getApplicationName()); |
There was a problem hiding this comment.
can you call this function at the layer that builds the telemetry connection config itself? This can be abstracted out of here.
There was a problem hiding this comment.
you mean under exportFailureLog(ctx) functions? or when we are constructing DRIVER_SYSTEM_CONFIGURATION
| DatabricksConnectionContextFactory.create(url, info); | ||
| DriverUtil.setUpLogging(connectionContext); | ||
| UserAgentManager.setUserAgent(connectionContext); | ||
| updateClientAppName(connectionContext.getApplicationName()); |
There was a problem hiding this comment.
We can set this in following order:
- set from UserAgentEntry connection property
- set from ApplicationName connection property
- set from ApplicationName client info property
| IDatabricksConnectionContext connectionContext = | ||
| DatabricksConnectionContextFactory.create(url, info); | ||
| DriverUtil.setUpLogging(connectionContext); | ||
| // This initializes both user agent headers and telemetry |
There was a problem hiding this comment.
Can we remove this comment? This seems misleading for someone having telemetry = OFF.
| import com.databricks.sdk.core.UserAgent; | ||
|
|
||
| /** Helper class for determining and setting user agent and client app name. */ | ||
| public class UserAgentHelper { |
There was a problem hiding this comment.
Any reason we split the existing UserAgentManager helper into a different UserAgent helper? (looks like an unnecessary split in my opinion.)
There was a problem hiding this comment.
I just wanted the fallback mechanism utility to be separate. But, I agree, merging makes sense.
| // Preserve existing custom headers (like User-Agent) and add/update auth headers | ||
| Map<String, String> newHeaders = new HashMap<>(customHeaders); | ||
| if (refreshedHeaders != null) { | ||
| newHeaders.putAll(refreshedHeaders); | ||
| } | ||
| customHeaders = newHeaders; |
There was a problem hiding this comment.
Minor improved version :
| // Preserve existing custom headers (like User-Agent) and add/update auth headers | |
| Map<String, String> newHeaders = new HashMap<>(customHeaders); | |
| if (refreshedHeaders != null) { | |
| newHeaders.putAll(refreshedHeaders); | |
| } | |
| customHeaders = newHeaders; | |
| if (refreshed != null) { | |
| customHeaders = new HashMap<>(customHeaders); | |
| customHeaders.putAll(refreshed); | |
| } |
| Map<String, String> headers = new HashMap<>(customHeaders); | ||
| headers.put("User-Agent", UserAgentManager.getUserAgentString()); | ||
| customHeaders = headers; |
There was a problem hiding this comment.
| Map<String, String> headers = new HashMap<>(customHeaders); | |
| headers.put("User-Agent", UserAgentManager.getUserAgentString()); | |
| customHeaders = headers; | |
| customHeaders = new HashMap<>(customHeaders); | |
| customHeaders.put("User-Agent", UserAgentManager.getUserAgentString()); |
| customHeaders = | ||
| refreshedHeaders != null ? new HashMap<>(refreshedHeaders) : Collections.emptyMap(); | ||
| // Preserve existing custom headers (like User-Agent) and add/update auth headers | ||
| Map<String, String> newHeaders = new HashMap<>(customHeaders); |
There was a problem hiding this comment.
Does that mean we don't add user-Agent info in our current thrift flow? Do we pass it from DatabricksHttpClient? I see that DatabricksHttpClient needs change too.
There was a problem hiding this comment.
Not really.
we do add user agent info in current thrift flow. thrift client is constructed from databrickshttpclient. While constructing, we do set userAgent in makeClosableHttpClient.
I've added logic to update user agent in thrift client because we want to update it when setClientInfo property as well.
There was a problem hiding this comment.
(Based on offline discussion) : SDK and thrift are not exhaustive set of places where this would be required. Any other call using HTTPClient will have the incorrect userAgent
| void resetAccessToken(String newAccessToken); | ||
|
|
||
| /** Update the user agent headers when application name changes */ | ||
| void updateUserAgent(); |
There was a problem hiding this comment.
we are going to remove this, right?
| } | ||
| try { | ||
| String userAgentString = UserAgentManager.getUserAgentString(); | ||
| if (!isNullOrEmpty(userAgentString) && !request.containsHeader("User-Agent")) { |
There was a problem hiding this comment.
do we need to do
if (!isNullOrEmpty(userAgentString) || !ObjectEquals(request.containsHeader("User-Agent"), userAgentString) {
inorder to replace the potentially stale userAgent (i.e., before customer sets it via session? )
There was a problem hiding this comment.
I discussed this also with @gopalldb , the plan is to introduce client info property and applicationname url param as fallback for userAgentEntry url param. UserAgentEntry always takes precedence.
samikshya-db
left a comment
There was a problem hiding this comment.
Minor comment, looks good otherwise! Thanks for the clean code!
what is the rationale for requiring two separate params to trace user activity? |
|
@jayantsing-db - this is in hope to reduce the number of Apparently, applicationName is a standard way to set the BI tool. More context here : https://databricks.slack.com/archives/C08AS8EFRNC/p1747302484928519?thread_ts=1747287041.406849&cid=C08AS8EFRNC |
Description
Added application name url param. This will be used to set client app name in telemetry. Earlier, it was set to null.
Now we follow fallback mechanism to set user agent and client app in telemetry
Testing
Manual
Script:
Additional Notes to the Reviewer
NO_CHANGELOG=true