feat(client): expose client cookie jar access

[serozhenka]

Resolves #476.

P.S. I know barely anything about Rust, so forgive if something is not up to with how it should be properly done. Feel free to contribute directly instead of asking me to make some changes, especially if it's Rust related.

[gemini-code-assist]

Summary of Changes

Hello @serozhenka, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the client's cookie management capabilities by exposing the underlying cookie jar directly through a new cookie_jar property. This feature provides developers with more granular control over cookie manipulation, whether they supply their own cookie storage or rely on the client's built-in functionality, improving flexibility and introspection.

Highlights

• Direct Cookie Jar Access: Introduced a cookie_jar property on both the asynchronous Client and synchronous BlockingClient classes, allowing direct programmatic access to the client's cookie storage.
• Flexible Cookie Jar Configuration: The cookie_jar property returns the Jar instance provided during client construction via cookie_provider, or the automatically created Jar if cookie_store=True was set without an explicit provider.
• Error Handling for Unconfigured Jars: Accessing cookie_jar on a client not configured for cookie storage will now raise an AttributeError, providing clear feedback to the user.
• Internal Rust Structure Update: The core Client struct in Rust was refactored to explicitly store the Jar instance, enabling its retrieval through the new property and ensuring proper management of the cookie provider.
• Comprehensive Testing: A new test case was added to tests/cookie_test.py to validate the correct behavior of the cookie_jar accessor under various configuration scenarios, including explicit providers, implicit storage, and unconfigured clients.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a cookie_jar property to both the async and blocking Client classes, allowing users to access and manipulate the cookie jar used by the client. This is a great feature addition.

My review focuses on a few areas:

• A critical logic bug in the Rust implementation that incorrectly handles client configuration when both cookie_provider and cookie_store=True are specified. I've provided a suggested fix.
• A missing type hint and incomplete docstring in the Python stub for the blocking client.
• A suggestion to enhance the new tests to cover the edge case that would have revealed the aforementioned bug.

The changes are otherwise well-implemented, and the new tests provide good coverage for the main use cases. Addressing these points will make the feature more robust and maintainable.

[0x676e67]

Overall, it's not bad. Some modifications have been made. The cookie_jar attribute doesn't need to throw an exception; it should return an Optional.

[serozhenka]

Optional cookie jar sounds like a code smell.
I mean it's at least 95% that you wouldn't want to disable cookies and just always do type assertions for those 5% sounds like an extra work that can be avoided. That's why I intentionally chose it to be AttributeError instead of None.

[0x676e67]

Claiming that an optional cookie jar is a “code smell” overlooks the benefits of clear and flexible design. Marking it as Optional explicitly indicates it may not always be available—a better signal than relying on AttributeError, which can conflate missing cookies with other programming errors. While handling None might add a minor overhead, it ensures safer, more predictable code and aligns well with modern type-checking tools like MyPy, ultimately reducing debugging efforts in edge cases.