fix(integration-mounts): mirror Slack message/DM roots so inbound reads down#170
Conversation
…ds down The Slack `messages` (top-level) and `users/<U>/messages` (DM) mounts were launched `sync=write-only`, so the daemon pushed our send-writeback command files up but did ZERO remote->local pulls — inbound top-level messages and DMs never materialized on disk, and the event-preview targeted read (which reads the local mounted file) returned "unavailable". Only the `threads` context root was `mirror`, which is why thread replies read down but top-level/DMs did not. Root cause: mountSpecsFor set syncMode via `isSlackWritebackCommandRoot(mountPath) ? 'write-only' : 'mirror'`. The `messages`/`users` roots are DUAL-PURPOSE (writeback command root AND inbound read surface), so write-only structurally disabled their read-down leg. Fix: mount all Slack roots `mirror`. Mirror is a strict superset of write-only — the local push/dispatch path (pushLocal) is byte-identical; it only ADDS the inbound pull — so send-writebacks still dispatch while inbound now reads down, matching the proven `threads` mirror mount. A fresh mirror full pull also backfills the messages/DMs missed while write-only. Durable cloud path-correctness for channel messages ships in cloud#2010 (deployed); DMs use the cloud#1997 D->U mapping (committed path is /slack/users/<U>/messages/<ts>/meta.json, confirmed readable). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Caution Review failedPull request was closed or merged during review No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR simplifies Slack integration mount synchronization by removing conditional logic that previously selected write-only mode for specific roots. All Slack mounts now force mirror mode unconditionally, enabling dual-purpose roots to support both writeback dispatch and inbound read materialization. Test expectations are updated to assert the new mirror behavior. ChangesSlack integration mount sync mode unification
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the synchronization mode for Slack message and DM roots from write-only to mirror in IntegrationMountManager to support both inbound read-downs and send-writebacks. The corresponding integration tests have been updated. The reviewer suggested deleting the now-unused slack-writeback-command-roots.ts module to clean up dead code.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| } from '@relayfile/sdk' | ||
| import { accountWorkspaceReadyRetryOptions, getAccountWorkspaceId, refreshCloudAuth, resolveCloudAuth } from './auth' | ||
| import { createPearMountLauncher } from './relayfile-mount-launcher' | ||
| import { isSlackWritebackCommandRoot } from './slack-writeback-command-roots' |
There was a problem hiding this comment.
With the removal of isSlackWritebackCommandRoot from this file, the entire module src/main/slack-writeback-command-roots.ts appears to be unused and can be safely deleted to clean up dead code.
|
Reviewed the current checkout and I removed the generated relay runtime artifact from the PR: Validation run:
Addressed comments
I could not verify remote CI status or GitHub mergeability from the provided local files, so I’m not marking this READY. |
|
Reviewed PR #170 against Validation passed:
GitHub API showed PR #170 is already merged. Required GitHub Actions checks on Addressed comments
|
|
Reviewed the current checkout for PR metadata Implemented fixes:
Validation run:
Addressed comments
|
1 participant
Problem (the DM / top-level read-down gap)
Inbound DMs and top-level channel messages never materialize on disk, so their event-preview shows "Message: unavailable." Root cause is purely mount config, not cloud/daemon:
messages(/slack/channels/<id>/messages) andusers(/slack/users/<U>/messages) mounts runsync=write-only(confirmed inmount.log+state.json). A write-only mount pushes our send-writeback command files up but does zero remote→local pulls (eventsCursor:null,lastEventAt:null, daemon never callspullRemote). So inbound content never reads down.threadscontext root issync=mirror— which is exactly why thread replies read down (verified post cloud#2010) but top-level/DMs do not.Confirmed jointly with relayfile-worker (daemon: write-only ⇒ no pulls, ever) and cloud-worker (
/slack/users/<U>/messages/<ts>/meta.jsonis a real readable committed file, feed emits the correct/users/Upath). So this is not cross-namespace, not alias/projection, not a read-404 — the mount simply never asks.Root cause in code:
mountSpecsForsetsyncMode: isSlackWritebackCommandRoot(mountPath) ? 'write-only' : 'mirror'. Themessages/usersroots are dual-purpose (writeback command root and inbound read surface), so write-only disabled their read-down leg.Fix
Mount all Slack roots
mirror. Per relayfile-worker (daemon source): mirror is a strict superset of write-only —pushLocal(dispatch) is byte-identical; mirror only adds the inbound pull. So send-writebacks still dispatch while inbound now reads down, matching the proventhreadsmount. A fresh mirror full pull also backfills the DMs/messages missed while write-only.messages→mirror is unblocked (post-#2010) andusers→mirror has no cloud dependency.Mirror adds a pull-side
snapshotDeletepass. It has strong partial-listing guards, butmessages/usersare the first mirror roots that also hold our outbound command files (unlikethreads, a pure read root). Need relayfile-worker's confirm that push-then-pull ordering (and/or cloud serving command files infs/tree) means a just-written-not-yet-pushed command file can't be deleted by a racing pull. Expected benign — and a bonus if so: mirror's pull would auto-delete dispatched command files (free delete-after-send). Holding merge on that trace.Mirror does a full remote pull → bulk-downloads message/DM history to local disk, which is broader than the "historical records not broadly downloaded" posture. Bounded for the scoped DM (single picked user) and this investigation channel; flag for the operator if a busier fleet is a concern (could scope to
users-only first).Tests
vitest run src/main/integration-mounts.test.ts→ 24 passed (updated the two Slack command-root tests to assertmirror+RELAYFILE_MOUNT_SYNC_MODE: 'mirror').tsc --noEmitclean.Rollout / batching
Needs a Pear rebuild+restart (syncMode applies at mount launch). Batch in one restart with: pear#169 (#2 stalled-revision detector, separate PR, ready) and the already-on-
mainpreview fixes (#159/#163). Working tree is clean — no uncommitted WIP to sweep.Draft pending the relayfile-worker pull-ordering gate + operator volume sign-off.
🤖 Generated with Claude Code