Skip to content

[python] Unify the OSS User-Agent format - #10307

Open
sundapeng wants to merge 1 commit into
apache:masterfrom
sundapeng:pypaimon-user-agent
Open

sundapeng wants to merge 1 commit into
apache:masterfrom
sundapeng:pypaimon-user-agent

Conversation

@sundapeng

@sundapeng sundapeng commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

Purpose

pypaimon hard-codes fs.oss.user.agent.features=pypaimon, which overwrites any features the user sets, and drops the DLF access tracking info (dlf.access-tracking.extended-info). The PyArrow S3 fallback sends only the AWS SDK's default User-Agent, so its OSS requests can't be attributed to pypaimon at all.

This gives OSS requests Paimon's unified User-Agent format, <module>(<transport>[;<feature>...])[ <extended>], which the REST client and the Java and Rust clients adopt as well:

  • module, features and extended come from the catalog options user-agent.module, user-agent.features and user-agent.extended, which REST requests read too ([python] Unify the REST User-Agent format #10309). fs.oss.user.agent.module/features/extended override the matching part for OSS only.
  • The default OSS backend fills the module and transport itself, so pypaimon/<version> leads the features.
  • dlf.access-tracking.extended-info, which DLF sends with the data token, is appended after the extended part, so it never replaces a user-set value.
  • The PyArrow S3 fallback (fs.oss.impl=legacy) has no User-Agent option. It sets AWS_SDK_UA_APP_ID when unset, which adds app/pypaimon/<version>; features and extended can't be carried on this path.
  • The version is the one build_info embeds at build time, which snapshots already record as the writer version.

Examples:

Backend Options User-Agent
default none JindoSDK/6.15.504-nextarch(coro_http;pypaimon/2.2.dev)
default user-agent.features=Flink, user-agent.extended=vvr, on a DLF catalog with access tracking enabled JindoSDK/6.15.504-nextarch(coro_http;pypaimon/2.2.dev;Flink) vvr tenantId/<uid> principalType/<type> userName/<name>
fs.oss.impl=legacy any aws-sdk-cpp/1.11.800 ua/2.1 api/S3 os/Linux#... app/pypaimon/2.2.dev md/GCC#14.2.1 ...

Related: #10309 (Python REST), #10306 (Java OSS), apache/paimon-rust#991 (Rust object storage). #10309 adds the same build_info.version().

Tests

oss_user_agent_test.py and jindo_file_system_test.py: 16 new cases; 51 tests passed together with oss_legacy_mode_test.py and pvfs_oss_filesystem_test.py. Also checked on a live DLF catalog with access tracking enabled: the OSS access log shows the tracking info after the configured extended part.

@sundapeng sundapeng changed the title [python] Align OSS User-Agent with Jindo [python] Unify the OSS User-Agent format Sep 28, 2026
pypaimon hard-coded fs.oss.user.agent.features=pypaimon, which overwrote
the user's features, and dropped dlf.access-tracking.extended-info. OSS
requests now follow Paimon's unified User-Agent format,
module(transport;features) extended.

Each part comes from fs.oss.user.agent.<part>, or else from the
catalog-wide user-agent.<part> shared with the REST client.
pypaimon/<version> leads the features, a configured module is passed to
the backend, and the access tracking info is appended after the extended
value. The PyArrow S3 fallback sets AWS_SDK_UA_APP_ID when unset, so its
requests carry app/pypaimon/<version>. The version is the one build_info
embeds at build time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant