Update graph.add docstring

[paul-paliychuk]

Important

Update graph.add docstring and clean up examples, with a version bump to 2.12.3.

• Docstring Updates:
  • Update graph.add docstring in src/zep_cloud/graph/client.py to remove subscription tier limits note.
  • Update graph.add_batch docstring in src/zep_cloud/graph/client.py to clarify batch processing order sensitivity.
• Example Cleanup:
  • Remove unused code in examples/chat_history/memory.py and examples/graph_example/entity_types.py.
  • Add tickets_example.py in examples/graph_example/ to demonstrate ticket purchasing scenario.
• Versioning:
  • Bump version in pyproject.toml and src/zep_cloud/core/client_wrapper.py from 2.12.2 to 2.12.3.

^{This description was created by for 10b1ed0. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 10b1ed0 in 2 minutes and 9 seconds. Click for details.

• Reviewed 371 lines of code in 7 files
• Skipped 0 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/zep_cloud/graph/client.py:146

• Draft comment:
  The updated docstring for graph.add is clear and concise. Consider adding additional context on the expected data format and any processing limitations if applicable.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is vague and speculative - it says "if applicable" and doesn't specify what exact information is missing. The docstring already has a complete API reference format with parameters, return type, and examples. The removal of subscription tier information appears intentional. The comment is asking the author to consider adding more info without being specific about what's missing. The docstring could potentially benefit from more details about the expected format of the 'data' parameter and any technical limitations. The comment points to a real documentation opportunity. While more docs could be helpful, this comment is too vague to be actionable. It doesn't specify what information is actually missing or needed. The existing docstring follows a standard format and appears complete for its purpose. Delete this comment since it is speculative ("if applicable") and not specific enough about what information needs to be added. The docstring already has a complete API reference format.

2. src/zep_cloud/graph/client.py:138

• Draft comment:
  Avoid using the parameter name 'type' as it shadows the built-in Python function. Consider renaming it (e.g., to 'data_type') for clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. src/zep_cloud/graph/client.py:280

• Draft comment:
  The docstring for add_fact_triple is very detailed and informative. Great work on providing comprehensive parameter descriptions. Ensure consistency in formatting with other methods.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. src/zep_cloud/graph/client.py:424

• Draft comment:
  The docstring for the 'search' method correctly notes that 'min_score' is deprecated. It might be beneficial to emphasize the deprecation in the parameter description to guide users away from its use.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. examples/graph_example/tickets_example.py:48

• Draft comment:
  There's a double space after the period in the assistant's message: "TicketSales. I found ...". It might be worth adjusting this for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the double space is technically present, this is example/demo data meant to show the API usage pattern. The double space doesn't affect functionality and isn't part of production user-facing content. The comment is extremely minor and doesn't improve code quality or functionality. Since this is example data, perhaps consistent formatting is still important for readability and professionalism, even in demos? While consistency is good, this level of nitpicking on demo data doesn't provide meaningful value and could distract from more important review feedback. The comment should be removed as it's too minor and focuses on cosmetic issues in example data rather than substantive code improvements.

Workflow ID: wflow_krktU1Li7xal4n7b

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Typographical error: The variable name enntl appears unclear. It might be a typo for something like entityTypes or entity_list. Please consider renaming for clarity.