Complete the photo story offline, at reconnect, and under the second viewer's refusal - #33
Conversation
…second viewer is refused by the server mint
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @LucaCappelletti94, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 4 days and 1 hour by commenting @sourcery-ai review. Upgrade to get a review now.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: LucaCappelletti94/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 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 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Reviewer's GuideCompletes R69-F by making the browser worker a locally capable offline peer: photo mutations persist durably and replay exactly once after a gated reconnect, frames remain locally served during idle recovery, and end-to-end tests prove both reconnect upload behavior and owner-only visibility with native-parity recovery documentation. Sequence diagram for offline photo staging and reconnect uploadsequenceDiagram
participant Tab
participant Worker
participant Replica
participant Pending as _connetto_pending
participant Server
participant FileServer
Tab->>Worker: Frame
Worker->>Replica: Commit photo mutation
Worker->>Pending: Persist pending mutation
Worker-->>Tab: Local frame result
Note over Worker,Server: connect_gate keeps upstream closed
Tab->>Worker: Open connect gate
Worker->>Server: Replay pending mutation
Server-->>Worker: R67 watermark acknowledgement
Worker->>FileServer: Upload chunks
Worker->>Server: Commit photo metadata
Server-->>Worker: Replicated available state
Worker-->>Tab: Fetch uploaded bytes
Sequence diagram for owner access and second-viewer refusalsequenceDiagram
participant Owner
participant Server
participant FileServer
participant Viewer
Owner->>Server: Resolve photo ticket
Server->>FileServer: Mint owner ticket
FileServer-->>Server: TicketRef
Server-->>Owner: Remote with fetch
Viewer->>Server: Resolve photo ticket
Server->>FileServer: Mint viewer ticket
FileServer-->>Server: TicketRefused
Server-->>Viewer: TicketRefused
Owner->>Server: Resolve photo again
Server->>FileServer: Mint owner ticket
FileServer-->>Server: TicketRef
Server-->>Owner: Remote with fetch
Flow diagram for locally served frames during recoveryflowchart LR
Frame[Frame arrives] --> Recovery{Idle recovery?}
Recovery -->|Yes| Local[Serve from replica or hub state]
Local --> Pending[Persist mutation to _connetto_pending]
Pending --> Attach[Attach or subscription replay owns connection]
Attach --> Replay[Replay exactly once under watermark]
Recovery -->|Attach/replay active| Held[Hold frame until ordering is safe]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3eefe9efbb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | HubEvent::ForgetRetired(_, _) | ||
| | HubEvent::RefusedContent(_) | ||
| | HubEvent::RetryRefused(_, _) | ||
| | HubEvent::Frame(_, _) |
There was a problem hiding this comment.
When one tab mutates a synced table during recovery, this newly served Frame is applied to the worker replica by handle_synced_mutation, but that path does not enqueue a LivePatch for the other tabs and ordinarily relies on the server echo to do so. Consequently, while the upstream remains offline, an already-subscribed sibling stays stale, whereas a tab subscribing afterward receives the new row from serve_snapshot; the tabs only converge after reconnect. The offline frame path should keep existing subscribers consistent with snapshots of the same replica.
Useful? React with 👍 / 👎.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #33 +/- ##
==========================================
+ Coverage 83.24% 83.27% +0.03%
==========================================
Files 114 114
Lines 25693 25693
Branches 25693 25693
==========================================
+ Hits 21388 21396 +8
+ Misses 3079 3073 -6
+ Partials 1226 1224 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Replying to the Codex P2 inline finding (comment 4044353005): Fixed. A word on scope first: sibling fan-out has always been echo-only on the connected path. R69-F made the window observable by serving Frames during idle recovery; it did not introduce the gap. The fix is in On reconnect the server echo arrives as a |
1 participant
This is R69 step F, the phase's last proof, and it ships one deliberate semantics change. A tab can now complete its whole protocol while the worker holds no connection, a staged photo lands in the browser store with its manifest and outbox entry and durable pending mutation, and nothing reaches the server until the connection opens, at which point R67's replay and watermark send each pending mutation exactly once and the upload and commit follow. That makes chapter 18's recovery table Frame row true in a new way, so the amendment ships in the same pull, frames are served from local state while the connection idles in recovery and stay held only while the attach or subscription replay owns the connection, with native parity and the watermark named in the rationale. The connect gate is a new boot option whose default keeps every existing worker boot byte-identical.
The offline suite proves the strong claim, staging with the socket never opened, the row visible on the mirror with content_state NULL, the server queried and still empty, then the gate opens, the outbox replays, chunks upload, and the flip to available arrives through replication with the bytes fetching back equal. The visibility suite proves the refusal travels the same mint path the owner's success takes, the second identity's resolve answers only TicketRefused, ordered owner Remote with fetch, viewer refused, owner Remote again on the same file id, so a local replica miss or upload timing cannot fake the pass, and the owner's access survives.
Verification, both new suites and photo_flow green through the live browser stack, the recovery regression trio green with the old pin rewritten to the new contract as a frame is served into pending during idle recovery, 57 lib plus all integration suites for connetto-web, fmt clean in all three workspaces and stable and nightly clippy clean for the two wasm workspaces. The plan row and both prose statuses now read D and E as the only open steps.
Summary by Sourcery
Complete the browser photo flow's offline staging, reconnect upload, and access-control proofs while preserving existing worker boot behavior by default.
New Features:
Enhancements:
Documentation:
Tests: