Graph edge search date time filters

[paul-paliychuk]

Important

Adds date filtering capabilities to graph edge searches with new DateFilter and ComparisonOperator types, updating version to 2.18.0.

• Behavior:
  • Adds DateFilter and ComparisonOperator types in date_filter.py and comparison_operator.py for date-based filtering.
  • Updates SearchFilters in search_filters.py to include created_at, expired_at, invalid_at, and valid_at fields with 2D date filter arrays.
• Versioning:
  • Updates version to 2.18.0 in pyproject.toml and client_wrapper.py.
• Imports:
  • Adds DateFilter and ComparisonOperator to __init__.py in zep_cloud and types.

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 8ea0111 in 2 minutes and 11 seconds. Click for details.

• Reviewed 190 lines of code in 7 files
• Skipped 0 files when reviewing.
• Skipped posting 7 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. pyproject.toml:3

• Draft comment:
  Version bump to 2.18.0 looks good. Consider adding a project description if applicable.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is purely informative about the version bump and suggests updating the project description, which violates the rules about not asking to update the PR description.

2. src/zep_cloud/__init__.py:10

• Draft comment:
  New exports (ComparisonOperator and DateFilter) have been added. Verify that any user documentation is updated to reflect these new types.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify that user documentation is updated, which violates the rule against asking the author to ensure or verify things. The comment does not provide a specific suggestion or point out a specific issue with the code.

3. src/zep_cloud/core/client_wrapper.py:20

• Draft comment:
  Header version updated to 2.18.0. Ensure this remains consistent with release and documentation.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is about ensuring consistency between the header version and the release/documentation. It is asking the author to ensure consistency, which violates the rule against asking the author to ensure things. Therefore, this comment should not be approved.

4. src/zep_cloud/types/__init__.py:12

• Draft comment:
  New type imports for ComparisonOperator and DateFilter are included. This aligns with the new API features.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, providing information about new type imports and their alignment with new API features. It does not offer any suggestions, ask for confirmation, or point out any issues.

5. src/zep_cloud/types/comparison_operator.py:1

• Draft comment:
  Auto-generated ComparisonOperator file: including 'typing.Any' in the union effectively weakens type checking. Consider revising if stricter typing is desired.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% Since this is an auto-generated file, any manual modifications would likely be overwritten on the next generation. The type definition comes from an API definition, so changes should be made there instead. Making changes here would be futile and possibly misleading. The comment makes a valid technical point about type safety. Maybe there's a way to configure the generator to produce stricter types? While the technical suggestion is sound, suggesting direct edits to auto-generated files is not the right approach. Any issues should be addressed in the API definition or generator configuration. Delete the comment because it suggests modifying an auto-generated file, which would be overwritten on the next generation.

6. src/zep_cloud/types/date_filter.py:11

• Draft comment:
  New DateFilter model added. The 'date' field is typed as a string; consider using a datetime type for better validation if an ISO or similar format is expected.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% Since this is an auto-generated file, any type changes would need to be made in the API definition, not in this file directly. The presence of datetime handling code suggests the string format is intentional for API compatibility. Making changes here would be overwritten on the next generation. The comment identifies a potentially valid concern about type safety. The presence of datetime handling code could indicate this is part of a larger design decision. However, since this is an auto-generated file, suggesting changes here is not actionable - changes would need to be made in the source API definition. Delete the comment because it suggests changes to an auto-generated file, which would be overwritten on the next generation.

7. src/zep_cloud/types/search_filters.py:12

• Draft comment:
  New date filter fields (created_at, expired_at, invalid_at, valid_at) have been added with clear docstrings explaining the 2D filter logic. Ensure the example syntax meets user expectations.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It violates the rule against making purely informative comments.

Workflow ID: wflow_ME07IOYRNq1Jv9D3

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