Conversation
dmurphy5
added this pull request to stack #44
September 24, 2026 22:02
dmurphy5
marked this pull request as ready for review
September 25, 2026 15:57
elliottkember
approved these changes
Sep 25, 2026
elliottkember
approved these changes
Sep 25, 2026
|
Ah. Yes good calls. Did we ship WiFi-only background upload for regular network requests already? We might want to ship this change fairly soon, I wouldn't want field note creations and such waiting for WiFi connections. |
elliottkember
approved these changes
Sep 27, 2026
Both changes come from the Diana readiness audit. Diana's Wi-Fi setting
applies to captures only, and Diana pauses captures only while field
note traffic keeps flowing. A queue-wide gate cannot express either.
RequestDescriptor.wifiOnly overrides the queue setting for that entry;
an entry that does not set it follows setWifiOnly, so toggling the
setting still moves queued captures. Both natives evaluate the
constraint per attempt and persist the per-entry value.
pause(scope) and resume(scope) take { keys?: string[] }. No keys means
the global gate, as before. Keys add to or remove from a persisted set.
An entry is paused when the gate is on or its key is in the set; each
entry that moves emits one state event; a scoped resume does not free
an entry the other gate still holds; an entry enqueued into a paused
scope starts paused. Pause produces no outcome and no attempt event.
The fake native in src/testing models both. Tests: JS 189, Android 307,
iOS 201.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The promotion PR says the script measures the time from mutate() to the first send, which decides the deferred in-process fast path. The step now exists, on both platforms, using the log clocks the harness prints. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
dmurphy5
force-pushed
the
dylan/v10-6-wifi-pause
branch
from
September 28, 2026 17:11
e69e46b to
af6b2a4
Compare
Author
No, this is that annoying Claude behavior where it references a decision + revision it made some time earlier in the session despite never being committed. |
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
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
Two small additions that Diana needs, found by reading how Diana uses uploads today.
1. Wi-Fi only, per request
Diana has a "Wi-Fi only" setting. It applies to capture uploads (large video files). It does not apply to small requests like a comment or a field note edit; those go out on any connection.
Before this PR, the setting was one switch for the whole queue. With it on, a comment would wait for Wi-Fi. With it off, a capture would use cellular data.
Now a request can say
wifiOnly: trueorwifiOnly: falsefor itself. A request that says nothing follows the queue switch. Diana's captures say nothing, so the user's setting still controls them. Every other request saysfalse.2. Pause by kind
Diana's "pause uploads" setting pauses captures only. Comments and edits keep flowing.
Before this PR,
pause()stopped the whole queue. Nowpause({ keys: [...] })pauses only the named kinds of request, andresume({ keys: [...] })lets them go again.pause()with no keys still pauses everything.How the library decides whether a request may run
flowchart TD A[Request is due] --> B{Whole queue paused?} B -- yes --> P[Wait] B -- no --> C{Its kind paused?} C -- yes --> P C -- no --> D{Wi-Fi only?<br/>request's own setting,<br/>else the queue setting} D -- yes, and no Wi-Fi --> P D -- no, or Wi-Fi present --> R[Send]Both settings are stored on the device, so they survive a restart. Pausing never loses a request; it only waits.
What to look at
pause()andwifiOnly: are the two rules easy to follow?scopein the JS, Android, and iOS suites.Test Plan
Both example apps build.
Compatibility
Checklist
README.md🤖 Generated with Claude Code