Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Why the
|
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
c1f4c38 to
156d66d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
156d66d to
b98950d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
BundleMonFiles updated (4)
Unchanged files (16)
Total files change +1.92KB +0.09% Groups updated (1)
Unchanged groups (2)
Final result: ✅ View report in BundleMon website ➡️ |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
rezk2ll
left a comment
rezk2ll
left a comment
There was a problem hiding this comment.
other stuff i found, on recipient side:
-
The live view (store) can be correct while a refresh (which reads the recipient drive pouch) shows a just-added file missing or a just-deleted file still present. Root cause is on the worker and pouch-link side ( the other two PRs ), but flagging it here.
-
in targets/browser/setupAppContext.js: The link that serves every shared-drive query is only added when
flag('dataproxy.queries.enabled')is truthy, but cozy-flags is not populated this early insetupApp, so on a cold load the link is missing and every drive query fails withNo link could handle operation(the folder shows "Something went wrong")
| [sortAttribute]: { $gt: null } | ||
| }) | ||
| .indexFields(['dir_id', 'driveId', sortAttribute]) | ||
| .sortBy([{ dir_id: sortOrder }, { [sortAttribute]: sortOrder }]) |
There was a problem hiding this comment.
skipping driveId triggers the "sort order should be the same than the indexed fields" warning and an ad-hoc index. we should add { driveId: sortOrder } to the sortBy
There was a problem hiding this comment.
Something to add to my skill ^^
| ? driveIdByFileId.get(filesInFolder[0]._id) | ||
| : undefined | ||
| const folder = await getParentFolder(client, folderId, driveId) | ||
| const files = filesInFolder.map(file => ensureFilePath(file, folder)) |
There was a problem hiding this comment.
we need to reapply driveId (already tracked in driveIdByFileId) onto each dispatched file.
Realtime docs arrive straight from the stack without the synthetic driveId (that field is added only by the data-proxy on replication). The dispatch reapplies path but not driveId, so cozy-client re-evaluates the shared-drive folder query (whose selector filters on driveId) against a doc that lacks it and drops the file from the live results. A refresh re-runs the pouch find and it reappears.
you can notice this when you rename a file in recipient side, it vanishes and reappear only on refresh. for owner it works fine
There was a problem hiding this comment.
OK for this one I think. Yes we alredy have the driveId we should reuse.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
…store For each recipient shared drive (owner === false), open a CozyRealtime socket scoped to that drive and feed created/updated/deleted io.cozy.files events into the same buffer/dispatch pipeline as own-instance files, so drive-backed useQuery results stay live. The global plugin subscription is unchanged (no regression).
Carry the originating driveId for each buffered drive file via a
module-level driveIdByFileId map. In processEvents, pass that driveId to
getParentFolder, which now resolves the parent through a drive-scoped
client.collection('io.cozy.files', { driveId }).statById() call (returning
the folder from data, not included). Own-file resolution is unchanged.
- Export __resetDriveIdByFileId() from FilesRealTimeQueries and call it in beforeEach to prevent the module-level Map from leaking across tests - Add mid-lifecycle test: asserts d1 stop() fires and CozyRealtime is constructed twice when the recipient-drive list changes on re-render - Assert resolved path in the drive-dispatch test (regression guard for drive-scoped path resolution)
derive and return recipientDriveIds (owner !== true) from the hook so components don't inline the recipient-detection logic. includes both owner === false and owner === undefined drives; excludes only owner === true.
…e parent locally - FilesRealTimeQueries now reads recipientDriveIds from useSharedDrives instead of filtering sharedDrives inline (owner === false removed) - getParentFolder drive branch replaced network statById with a local-pouch fetchQueryAndGetFromState call using forceLink:'dataproxy' + driveId, keeping the realtime path fully reactive and off the network - updated spec: useSharedDrives mocks include recipientDriveIds; drive path-resolution test asserts fetchQueryAndGetFromState options instead of statById
…ggregate Rewrites useRecentFiles to remove the imperative dataProxy.recents() snapshot and useDataProxy dependency. Returns a scopeQueries array (one own-files scope + one per recipient shared drive) that the Recent view mounts; results are merged, deduped by _id, sorted by updated_at desc, filtered for trashed, and capped at 50. Degrades to own-files-only when no DataProxyLink is present in client.links. Updates Recent view wiring and all three spec files.
… statById+manual realtime
…load While `isSettingsLoaded` is false, the query is gated off and useQuery returns `fetchStatus: 'pending'`. `getFolderViewState` does not treat 'pending' as loading, causing a brief empty-state flash. Normalise to 'loading' (with no lastUpdate) so the skeleton is shown instead.
When the user is viewing a shared-drive folder and loses access (drive deleted or removed as recipient), useSharedDrives updates via realtime; the new useEffect detects the missing driveId and navigates away with a secondary alert instead of silently showing an empty folder.
…nRevokedDrive hook moves the revocation-redirect useEffect out of SharedDriveFolderView into a dedicated hook to reduce cyclomatic complexity (14→prior level) and make the redirect logic independently testable
Extract a shared recents Mango definition reused by buildRecentQuery and buildRecentsScopedQuery; extract a helper from processEvents; dedupe the similar realtime, recents-query and shared-drive-folder tests. Default recipientDriveIds to [] so mounting FilesRealTimeQueries with a partial useSharedDrives mock does not throw.
…h smells Extract actions setup into useSharedDriveFolderActions hook and render body into SharedDriveFolderContent to bring cyclomatic complexity and LoC of SharedDriveFolderView within CodeScene thresholds.
cozy-flags is not populated when setupApp runs, so the DataProxy link was dropped and every shared-drive query failed with 'No link could handle operation' until the flag happened to be cached from a prior session.
The sort skipped driveId while the index declared it, so pouchdb-find could not use the declared index and fell back to building an ad hoc one.
Realtime docs arrive without the synthetic driveId, so the driveId-filtered folder query dropped the file from its live results on every update until a manual refresh.
8afa9e9 to
ffbaa16
Compare
There was a problem hiding this comment.
(4 files improve in Code Health)
Our agent can fix these. Install it.
Gates Passed
View Improvements
| File | Code Health Impact | Categories Improved |
|---|---|---|
| useSharedDriveFolder.spec.jsx | 9.39 → 10.00 | Code Duplication |
| useSharedDriveFolder.tsx | 8.70 → 10.00 | Complex Method, Complex Conditional |
| Empty.jsx | 9.55 → 9.61 | Complex Method |
| SharedDriveFolderView.jsx | 9.03 → 10.00 | Complex Method |
Quality Gate Profile: The Bare Minimum
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.
This branch has not been deployed
2 participants
Update: reactivity now comes from the data-proxy push, no per-drive websocket
Instead of opening one
CozyRealtimesocket per recipient drive in every Drive tab, the shared worker now pushes shared-drive document changes to Drive.FilesRealTimeQuerieslistens for those pushes onwindowand feeds them into the same buffering and dispatch pipeline, so the store updates the same way, without any Drive-side websocket.FilesRealTimeQueriesno longer constructsCozyRealtime; it consumes{ type: 'DATAPROXYMESSAGE', payload: { kind: 'realtime', event, doctype, driveId, doc } }messages (origin filtered to the data-proxy) and reuses the existing buffers,driveIdByFileId, path resolution and dispatch.onSync+ forwarder) is in feat: relay shared-drive changes to drive via realtime push cozy/cozy-web-data-proxy#63, driven by the data-proxy periodic sync.Original description below.
Summary
Goal: make the Recent view and the shared-drive folder listing update live (trash, rename, move, create) for files inside shared drives, the way they already do for a user's own files.
Approach: shared-drive files are replicated locally by the data-proxy worker under a per-drive doctype. We let any view query them as ordinary reactive
io.cozy.filesdocuments through cozy-client's store, by adding adriveIdquery option that reads the drive's database while keeping the documents typedio.cozy.files. Remote changes flow into the same store slice through one realtime socket per recipient drive.The work is split across three repositories:
forceLinkquery option plus driveId-aware shared-drive reads in cozy-pouch-link (feat: support driveid-scoped reactive queries via forcelink cozy-client#1691).driveIdoption through to its pouch link (feat: guard driveid forwarding through the data-proxy worker cozy/cozy-web-data-proxy#62).io.cozy.filesstore.What this PR contains:
FilesRealTimeQueriesopens oneCozyRealtimeper recipient shared drive (owneris false) and dispatches created, updated and deleted events into the store asio.cozy.files, reusing the existing buffering and dispatch pipeline.Still in progress before this is ready for review:
owner === false; confirm the sharings API always returns a booleanowner, or widen the filter so no recipient drive is silently skipped.