Conversation
✅ Deploy Preview for graypaper-reader ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a ChangesReadableStream Async-Iterator Polyfill
Search Match Summarization and Query State Tracking
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Contributor
Visual Regression Test Report ✅ PassedGithub run id: 28014861182 🔗 Artifacts: Download |
# Conflicts: # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-header-options-menu-dark-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-header-options-menu-light-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-header-version-dropdown-light-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-sidebar-overlay-closed-dark-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-sidebar-overlay-closed-light-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-sidebar-overlay-dark-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-view-closed-light-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-view-opened-dark-mode-linux.png # tools/snapshot-tests/tests/split-screen.spec.ts-snapshots/split-view-via-url-light-mode-linux.png
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/Search/Search.tsx`:
- Around line 224-249: The issue is that when the query becomes empty, the code
calls search("") on lines 231-233, which can trigger the updateMatches callback
and cause onSearchFinished(true) to be called, overwriting the
onSearchFinished(false) that was already called on line 230 during the clear
path. To fix this, remove the search("") call block (lines 231-233) entirely, or
introduce a ref flag to track that we are in a clearing state and use it in the
updateMatches callback to prevent onSearchFinished(true) from being called when
clearing. This ensures the search state remains cleared and does not flip back
to active after the empty-query clear.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 51d9fdf8-c7e5-494f-b92b-4bdab7402244
📒 Files selected for processing (2)
src/components/Search/Search.spec.tssrc/components/Search/Search.tsx
✅ Files skipped from review due to trivial changes (1)
- src/components/Search/Search.spec.ts
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/utils/readableStreamAsyncIteratorPolyfill.ts (1)
18-31: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winRelease the reader lock when
read()rejects.If
reader.read()rejects (errored stream),isDonestaysfalseand the lock is never released, leaking the reader and leaving the stream locked. The native async iterator releases the lock and marks itself done on error.♻️ Proposed fix
async next() { if (isDone) { return { done: true, value: undefined as T }; } - const result = await reader.read(); + let result: ReadableStreamReadResult<T>; + try { + result = await reader.read(); + } catch (error) { + isDone = true; + reader.releaseLock(); + throw error; + } if (result.done) { isDone = true; reader.releaseLock(); return { done: true, value: undefined as T }; } return { done: false, value: result.value }; },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/readableStreamAsyncIteratorPolyfill.ts` around lines 18 - 31, The next() method does not handle errors when reader.read() rejects. When an error occurs during read(), isDone remains false and the reader lock is never released, causing a resource leak. Wrap the reader.read() call in a try-catch block that catches any errors, sets isDone to true, calls reader.releaseLock(), and then re-throws the error to propagate it to the caller, ensuring the reader lock is always released whether the read succeeds or fails.src/utils/readableStreamAsyncIteratorPolyfill.spec.ts (1)
34-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider covering the early-termination / cancel path.
The
return()branch (lock release +reader.cancel, and thepreventCanceloption) is the most intricate logic in the polyfill but is currently untested. A test thatbreaks out of thefor awaitloop and asserts the lock is released /cancelhonored would close the gap.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/readableStreamAsyncIteratorPolyfill.spec.ts` around lines 34 - 53, Add a new test case that covers the early-termination path of the async iterator polyfill. Create a test that instantiates a ReadableStream and uses a for await loop to iterate over its values, but breaks out of the loop before all values are consumed (simulating early termination). Verify that the lock is properly released after the break by checking that subsequent operations on the reader work correctly, and assert that the reader.cancel() method is called/honored when the iteration is terminated early via the return() method in the polyfill.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/utils/readableStreamAsyncIteratorPolyfill.spec.ts`:
- Around line 34-53: Add a new test case that covers the early-termination path
of the async iterator polyfill. Create a test that instantiates a ReadableStream
and uses a for await loop to iterate over its values, but breaks out of the loop
before all values are consumed (simulating early termination). Verify that the
lock is properly released after the break by checking that subsequent operations
on the reader work correctly, and assert that the reader.cancel() method is
called/honored when the iteration is terminated early via the return() method in
the polyfill.
In `@src/utils/readableStreamAsyncIteratorPolyfill.ts`:
- Around line 18-31: The next() method does not handle errors when reader.read()
rejects. When an error occurs during read(), isDone remains false and the reader
lock is never released, causing a resource leak. Wrap the reader.read() call in
a try-catch block that catches any errors, sets isDone to true, calls
reader.releaseLock(), and then re-throws the error to propagate it to the
caller, ensuring the reader lock is always released whether the read succeeds or
fails.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 28e54ac3-cfad-43eb-a473-078dfa2db67e
📒 Files selected for processing (3)
src/main.tsxsrc/utils/readableStreamAsyncIteratorPolyfill.spec.tssrc/utils/readableStreamAsyncIteratorPolyfill.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main.tsx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ReadableStreamasync-iteration polyfill for Safari versions that expose streams without.values()/[Symbol.asyncIterator].pageMatchesarrays.RegExp.escapepolyfill so this branch stays minimal while Safari testing confirms whether it is needed.Why
pdf.js uses
for await (... of readableStream)insidePDFPageProxy.getTextContent. On affected Safari builds, missing stream async iteration causes text extraction to fail withTypeError: undefined is not a function, so search indexing returns zero results.Fixes #446.
Validation
ReadableStream.prototype.valuesand[Symbol.asyncIterator]deleted before app load:protocolreturns 47 results in 18 sections.npm run test -- --runnpm run qanpm run buildnpm run qahook passedSummary by CodeRabbit
New Features
Tests