Skip to content

feat (Synchronizer): forward realm-context header on all Polaris requests - #262

Open
saidixith002 wants to merge 2 commits into
apache:mainfrom
saidixith002:feat/realm-context-header
Open

feat (Synchronizer): forward realm-context header on all Polaris requests#262
saidixith002 wants to merge 2 commits into
apache:mainfrom
saidixith002:feat/realm-context-header

Conversation

@saidixith002

Copy link
Copy Markdown
Contributor

Summary

Polaris supports a configurable realm-context header for routing requests to a specific realm:

polaris.realm-context.header-name=Polaris-Realm # or a custom name, e.g. catalog-realm
polaris.realm-context.realms=POLARIS,LAKEHOUSE
polaris.realm-context.require-header=false

polaris-synchronizer currently sends no realm header on any request, which breaks (or silently defaults to the wrong realm) when talking to a Polaris instance with
multi-realm support enabled. This PR forwards a configurable realm header on every outgoing call to Polaris — both Management API calls and Iceberg REST Catalog calls.

Changes

Two new properties are accepted via --source-properties / --target-properties:

Property Required Default Description
realm No (unset) The realm value to send (e.g. POLARIS). If unset, no header is sent at all — fully backward compatible with single-realm deployments and
Polaris's own require-header=false default.
realm-header-name No Polaris-Realm Overrides the header name. Must match the target Polaris instance's configured polaris.realm-context.header-name.

Source and target are configured independently, since each can point at a different realm.

The header is wired into all three client-side call paths:

  • PolarisApiService — added to the Management API's request interceptor, alongside the existing OAuth session headers.
  • PolarisIcebergCatalogService — added as a header.<realm-header-name> catalog property, which Iceberg's RESTSessionCatalog automatically converts into an HTTP
    header on every standard REST catalog call (list/create/drop namespaces & tables, etc.) — verified via bytecode inspection of iceberg-core that this is a genuine built-in
    convention (RESTSessionCatalog.configHeaders()RESTUtil.extractPrefixMap(properties, "header.")).
  • PolarisCatalog#loadTable(TableIdentifier, String etag) — this method builds a raw HttpRequest manually to support ETag handling and bypasses the catalog's normal
    header pipeline, so the header is attached explicitly here too.

CLIUtil documentation for --source-properties/--target-properties was updated to describe both new keys.

Backward compatibility

No behavior change for existing users: realm is optional and omitted by default, so no header is sent unless explicitly configured — matching Polaris's own
require-header=false default.

Testing

No existing unit tests cover PolarisApiService, PolarisIcebergCatalogService, or PolarisCatalog directly (they wrap live HTTP clients), so no new tests were added —
consistent with current coverage for these classes. Manually verified against a Polaris instance configured with polaris.realm-context.require-header=true that requests
fail without realm set and succeed once it's provided.

Polaris supports a configurable realm-context header
(polaris.realm-context.header-name, default Polaris-Realm) for
selecting which realm a request targets. The synchronizer client sent
no such header on any call. Adds two new source/target properties:
realm (the value to send; omitted entirely if unset) and
realm-header-name (override, defaults to Polaris-Realm), forwarded on
Management API calls, standard Iceberg REST catalog calls via the
existing header.* property convention, and the manual loadTable ETag
path that bypasses that convention.
@saidixith002 saidixith002 changed the title feat(Synchronizer:): forward realm-context header on all Polaris requests feat (Synchronizer): forward realm-context header on all Polaris requests Jul 30, 2026
AuthenticationSessionWrapper's own HTTPClient never attached the realm
header, so the initial client_credentials token fetch went out unrealmed
and some deployments reject it before any management/catalog API call
ever happens.
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