Skip to content

Add SessionCatalog trait - #2836

Open
DerGut wants to merge 4 commits into
apache:mainfrom
DerGut:session-catalog
Open

Add SessionCatalog trait#2836
DerGut wants to merge 4 commits into
apache:mainfrom
DerGut:session-catalog

Conversation

@DerGut

@DerGut DerGut commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

What changes are included in this PR?

This PR introduces the session-aware catalog API:

  • SessionCatalog and SessionCatalogBuilder
  • SessionContext, including identity, properties, and credentials
  • Credential, which redacts secrets from debug output and zeroizes them

The REST implementation and catalog refactor have been split into a follow-up PR.

Are these changes tested?

  • cargo test -p iceberg --lib

@CTTY

CTTY commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

I literally just proposed this idea last week in the rust community sync, and very happy to see some actual work already!

There are some existing work on AuthManager/Session, maybe we should merge the effort? #2815

@DerGut

DerGut commented Jul 17, 2026

Copy link
Copy Markdown
Contributor Author

@CTTY What a coincidence! I was planning to attend myself to push for it, so thanks for covering the topic! 🙏

On #2815, this is perfect timing too. I was about to start some work on the AuthManager (according to #2774 (comment)) but that doesn't seem necessary anymore 👏
Let me take a look at the PR to watch out for integration issues with the SessionCatalog work :)

They're 100% related, but it already looks like a reasonable split to contribute them sequentially.

@DerGut DerGut changed the title Add session-aware catalog API Add SessionCatalog trait Jul 28, 2026
@DerGut
DerGut force-pushed the session-catalog branch from 02ed31c to ad60abb Compare July 28, 2026 22:21
@DerGut
DerGut marked this pull request as ready for review July 28, 2026 22:38
/// Note that the session_id may be used for caching session-scoped state
/// and re-use of a session_id with different session context may result in
/// unexpected behavior.
session_id: String,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: since reusing a session_id across different contexts is documented as hazardous, maybe default it in the builder (#[builder(default = Uuid::new_v4().to_string())]) so the safe thing is also the default?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great idea! Will do 🙇

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed in 4148500 👍

///
/// It is redacted from logs and automatically zeroized.
#[derive(Clone)]
pub struct Credential(Zeroizing<String>);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is structurally identical to the SensitiveString I added in #2838 (per your suggestion there) — once this lands I'm happy to swap #2838 over to iceberg::Credential so we end up with one type.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is dual use! Sounds good to me. If you have a preference on the naming, SensitiveString is definitely the more generally plausible name. Credential works better in the current state where we're only dealing with credentials.
I'll take a look through the Java codebase to see whether there's other places where sensitive strings could be handled.

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.

3 participants