Skip to content

Tests/interop complete - #41

Open
sagar448 wants to merge 20 commits into
mainfrom
tests/interop-complete
Open

Tests/interop complete#41
sagar448 wants to merge 20 commits into
mainfrom
tests/interop-complete

Conversation

@sagar448

@sagar448 sagar448 commented Apr 2, 2025

Copy link
Copy Markdown
Contributor

Important

Introduce interop testing framework for browser state management with Redis, using zip archives and cross-language compatibility.

  • Behavior:
    • Switch from tar to zip archives in RedisStorage for session storage, aligning with TypeScript.
    • Add base64 encoding for Redis storage in upload() and download() methods.
    • Validate key_prefix format to exclude colons in both Python and TypeScript implementations.
  • Testing:
    • Add Python interop tests in run_python_tests.py and test_browser_state.py for session creation and verification.
    • Add TypeScript interop tests in run_ts_tests.mjs and test_browser_state.mjs for session creation and verification.
    • Implement cross-browser and cross-language tests in run_all.sh.
    • Setup scripts setup.sh for environment preparation.
  • Misc:
    • Add test.html for browser state testing.
    • Update package.json for TypeScript dependencies.

This description was created by Ellipsis for 127bd83. It will automatically update as commits are pushed.

bigboateng and others added 20 commits April 1, 2025 03:40
…ferent, implemented manual extraction for compatibility
@sagar448
sagar448 requested a review from bigboateng April 2, 2025 19:47
@bigboateng
bigboateng marked this pull request as ready for review April 2, 2025 22:59

@ellipsis-dev ellipsis-dev Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

❌ Changes requested. Reviewed everything up to 127bd83 in 2 minutes and 19 seconds

More details
  • Looked at 1056 lines of code in 10 files
  • Skipped 4 files when reviewing.
  • Skipped posting 9 drafted comments based on config settings.
1. python/browserstate/storage/redis_storage.py:207
  • Draft comment:
    Session ID extraction in list_sessions relies on fixed string slicing. Ensure all keys strictly follow the expected format to avoid mis-parsing.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50%
    None
2. typescript/src/storage/RedisStorage.ts:523
  • Draft comment:
    Regex-based session ID extraction in listSessions might be brittle. Consider a more robust key parsing method.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50%
    None
3. typescript/src/storage/RedisStorage.ts:188
  • Draft comment:
    Dynamic import error handling: Ensure that any failure in initializing the Redis client is clearly propagated for production debugging.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50%
    None
4. python/browserstate/storage/redis_storage.py:207
  • Draft comment:
    Consider refactoring the session ID extraction logic. Splitting the key string using a computed index may be fragile if key format ever changes. A regex or explicit parsing based on the known format could improve clarity and robustness.
  • 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 current implementation does seem a bit fragile since it relies on exact string positions. However, the key format is well-defined and validated (key_prefix can't contain colons, format is enforced in _get_key()). The code is part of a changed section where they switched from tar to zip and updated the key handling. The suggestion is valid but may not be critical enough to warrant immediate change.
    The current implementation works correctly and is actually quite explicit about the key format. A regex might actually make it less readable.
    While the suggestion has merit, the current code is sufficiently robust given the strict key format validation and clear key construction pattern used throughout the class.
    The comment should be deleted as the current implementation, while not perfect, is adequately robust and clear given the context.
5. typescript/src/storage/RedisStorage.ts:424
  • Draft comment:
    The metadata property 'fileCount' is hardcoded to 0. If a file count is useful for future debugging or validation, consider computing the actual number of files in the session directory.
  • 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.
6. typescript/src/storage/RedisStorage.ts:523
  • Draft comment:
    The regex used in listSessions for extracting the session ID works, but its pattern directly mirrors the key format. Consider adding a comment or using a helper to make the intended format explicit for easier future maintenance.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50%
    None
7. tests/interop/python_tests/test_browser_state.py:77
  • Draft comment:
    Typographical suggestion: The comment on line 77 uses curly/smart quotes around “metadata” and “we’ll”. Consider replacing them with standard straight quotes ("metadata", "we'll") 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 = 0% vs. threshold = 50%
    This is a purely stylistic suggestion about quotes in a comment, not about actual code. It doesn't affect functionality or code quality. The comment is readable and clear as-is. This kind of nitpicking about comment formatting is not valuable and could be distracting.
    Maybe consistent quote style throughout the codebase is important for this project? Maybe there's a style guide that mandates straight quotes?
    Even if there is a style guide, enforcing quote style in comments (not code) is too minor to be worth a PR comment. This would be better handled by an automated formatter if it's really important.
    Delete this comment. The suggestion is too minor and focuses on pure formatting of comments rather than anything that impacts code quality or functionality.
8. tests/interop/python_tests/test_browser_state.py:154
  • Draft comment:
    Typographical suggestion: The comment on line 154 uses curly quotes in “real” migration. Consider switching them to standard straight quotes ("real") for clarity and consistency.
  • 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%
    This is an extremely minor stylistic suggestion about quote characters in a comment. It doesn't affect functionality. It's not about code quality or logic. It's the kind of nitpicky comment that creates noise without adding value. The current quotes are perfectly readable and clear.
    Maybe consistency in documentation style is important for readability and professionalism? Some style guides might have specific requirements about quote usage.
    While consistency is good, this level of nitpicking about quote characters in comments is excessive and distracts from more important code review concerns. There's no evidence of a style guide requirement here.
    Delete this comment as it's too minor and doesn't improve code quality or functionality.
9. tests/interop/run_all.sh:45
  • Draft comment:
    Typographical note: The text 'cross‑language' (as seen in the comment on line 45 and elsewhere) is using a non-standard hyphen character. Consider replacing it with a standard ASCII hyphen ('-') for better consistency and compatibility.
  • 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 technically correct about the non-standard hyphen, this is a very minor issue in comments that doesn't affect functionality. The hyphen displays fine in modern editors and terminals. Comments are documentation, not logic. According to the rules, we should not make purely informative comments or comments about obvious/unimportant issues.
    The non-standard hyphen could potentially cause issues in some environments or when copying/pasting. It's also inconsistent with standard programming conventions.
    While true, this is still a very minor stylistic issue in comments that doesn't impact functionality. The rules explicitly state not to make comments that are obvious or unimportant.
    Delete this comment as it violates the rules about not making purely informative comments or comments about unimportant issues.

Workflow ID: wflow_nElTy3XpisNbwbSZ


Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.


# Extract zip file to target directory
with zipfile.ZipFile(zip_file_path, 'r') as zip_ref:
zip_ref.extractall(target_path)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Potential Zip Slip vulnerability: The ZIP extraction does not verify file paths. Consider validating entries before extraction to prevent path traversal.

Comment thread tests/interop/setup.sh
if [ ! -f "package.json" ]; then
npm init -y
fi
npm install playwright ts-node ioredis --no-save

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Duplicate installation of Playwright detected. 'npm install playwright ts-node ioredis --no-save' is run and shortly after 'npm install playwright' is executed again. Consider removing the redundant installation.

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.

2 participants