Give both web demos a photos surface and register their browser suites - #34
Conversation
![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 2 hours 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 GuideBoth Yew and Dioxus demos now support authenticated, owner-scoped photo staging and display through the worker/tab content protocol, with policy-aware replicated schemas, end-to-end browser coverage, default CI suite registration, and corresponding project-status updates. Sequence diagram for demo photo staging and displaysequenceDiagram
actor User
participant Dashboard
participant TabContent
participant Worker
participant Replica
participant FileServer
User->>Dashboard: Pick image file
Dashboard->>TabContent: stage(blob, MimeClass::Jpeg, client, closure)
TabContent->>FileServer: Stage content
TabContent->>Replica: closure transaction
Replica->>Replica: Insert orders and photos with owner_id
Dashboard->>Worker: replay_pending()
Worker->>FileServer: Commit staged content
FileServer-->>Replica: Replicate content_state available
Dashboard->>TabContent: resolve(file_id)
TabContent->>FileServer: Resolve signed URL
FileServer-->>Dashboard: Remote URL
Dashboard-->>User: Render photo
Entity relationship diagram for owner-scoped photoserDiagram
orders ||--o{ photos : contains
orders {
UUID id PK
TEXT owner_id
BIGINT quantity
}
photos {
UUID id PK
UUID order_id FK
TEXT owner_id
BYTEA content_id
TEXT content_state
}
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: 8e3b222c6c
ℹ️ 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".
| let mut transport = | ||
| MessageTransport::<BroadcastChannel>::with_peer_liveness(&wire, workers::DB_ALIVE_LOCK) | ||
| .map_err(|err| JsValue::from_str(&err.to_string()))?; | ||
| let content = Rc::new(TabContent::new(&mut transport)); |
There was a problem hiding this comment.
After a worker or leader replacement, with_reconnect uses tab_wire_factory to create a fresh wire, but this TabContent remains bound to the original boot transport. BroadcastChannel sends to that abandoned wire still report success, so resolves wait until timeout and newly staged blobs go to the old channel while their mutations go to the new one, causing the hub to reject or roll back the photo. The content lane needs to be recreated or rebound alongside every reconnect; the Dioxus demo has the same pattern.
Useful? React with 👍 / 👎.
| let available: Vec<(rosetta_uuid::Uuid, Vec<u8>)> = photo_rows | ||
| .iter() | ||
| .filter(|p| p.content_state.as_deref() == Some("available")) | ||
| .map(|p| (p.id, p.content_id.clone())) |
There was a problem hiding this comment.
When a photo is staged while the upstream connection is unavailable, its content_state remains null and TabContent::resolve would return TabResolved::Local; filtering exclusively for available prevents that resolution entirely, leaving the newly picked offline photo as a blank pending row. The resolver also needs to handle and retain an object URL for the local result. The identical filter in the Dioxus surface has the same problem.
Useful? React with 👍 / 👎.
| let key: Vec<rosetta_uuid::Uuid> = available.iter().map(|(id, _)| *id).collect(); | ||
| use_effect(move || { | ||
| let _key = key.clone(); | ||
| let available = available.clone(); |
There was a problem hiding this comment.
If the dashboard mounts before any photo is available, this effect runs with an empty captured vector and never subscribes to a reactive signal: _key is only an ordinary Vec, not a signal read. Consequently, the later pending-to-available live-query update does not rerun the resolver and newly uploaded photos keep an empty image cell. Read the live photo signal inside the effect or use an explicit reactive dependency.
Useful? React with 👍 / 👎.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #34 +/- ##
==========================================
- Coverage 83.27% 83.25% -0.03%
==========================================
Files 114 114
Lines 25700 25700
Branches 25700 25700
==========================================
- Hits 21402 21396 -6
- Misses 3073 3079 +6
Partials 1225 1225
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:
|
6643f29 to
41e0089
Compare
|
1 participant
Both web demos now speak photos. Their workers boot with photos in the upstream subscription set and a content namespace, their dashboards gained a photos panel that stages a picked jpeg or png through the tab-to-worker protocol with the photos row inserted in the same transaction, watches content_state arrive as available through replication, and renders the image from the resolved signed URL, refetching the resolve rather than caching the URL because tickets expire. The tab now splits a TabContent half off its transport before the connection, which is the same seam the wasm-smoke suites use.
Getting the demos onto the browser stack surfaced a real coupling this PR now makes explicit. The connection handshake compares a hash of the schema SQL text, so a demo whose schema.sql merely means the same thing as wasm-smoke's is rejected at connect with SchemaOutdated, which is exactly how the first draft of this branch failed. Each demo's schema.sql is therefore now a byte-identical copy of examples/wasm-smoke/schema.sql including comments, and the first test of each new suite is a plain orders insert observed through the demo's own boot path, a permanent drift detector that fails at the handshake the instant the two files diverge, so no header comment can be added to the schema files and none is warranted, the guard belongs in the suites and is commented there. The demos gained policies.sql verbatim from wasm-smoke, and owner_id is carried by every insert, add_order and staging closure alike, because the stack's reader role is a non-superuser and its RLS is genuinely enforced. Both demo suites are registered in the browser stack's default discovery, so they run in CI and not just in a local invocation. The one file touched outside the two demo workspaces and the registration is examples/wasm-smoke/Cargo.lock, where a build moved windows-sys forward from 0.52 to 0.61, that stays, per the no-holdback rule the graph moves forward.
Verification, yew suite 2 passed 0 failed and dioxus suite 2 passed 0 failed on the live browser stack under the stack port lock, the dioxus run re-executed after a post-review rsx fix to the panel, stable and nightly clippy clean for both demo workspaces for wasm32 and for the harness workspace, fmt clean across all three, and zero warnings from cargo check --all-targets in each demo. The plan row, the R69 section prose and the chapter status line now record E as built with the desktop demo as the only open surface.
Summary by Sourcery
Equip both web demos with replicated photo upload and display flows, enforce their schema and row-security alignment, and run their browser suites by default.
New Features:
Bug Fixes:
Enhancements:
CI:
Documentation:
Tests:
Chores: