onIosUpload runs sync local, sync remote, hash and handle backup
sequentially. on the bg refresh task path that's a 20s budget from
iOS, and sync + hash usually eat all of it before backup gets a turn
to enqueue any candidates.
these phases don't actually depend on each other. local + remote sync
touch different tables. hash works off whatever's already in drift.
handle backup reads candidates and just enqueues to URLSession bg.
anything one phase produces in this fire shows up to the others on
the next fire, and server-side dedup catches the rare race where
backup enqueues something sync remote was about to mark as already
uploaded.
so this runs all four concurrently via Future.wait, with hash getting
the full maxSeconds-1 budget instead of a fixed 5s. outer budget
timeout still caps everything before iOS expires.
second small change: getAssetsToHash orders by createdAt DESC instead
of id ASC to match getCandidates. when hash runs inside a refresh
fire it processes recent photos first.
#27666 removed LocalNotificationService with the legacy stack, which
was the only place calling FlutterLocalNotificationsPlugin().initialize().
without it, ios never prompts for the notification perm on fresh
installs so background_downloader notifications get dropped silently.
restores the init in the same spot the deleted call used to live.
* hide hidden person from memories
* clean up
* fix united test
* clean up
* moved sql to inline, rebased
* clean up
* clean up again
* chore: sync sql
---------
Co-authored-by: Jason Rasmussen <jason@rasm.me>
* feat(server)!: add owned filter to albums API
BREAKING CHANGE: GET /albums with no parameters now returns all accessible albums (owned + shared-with-me) instead of only owned albums.
* document tri-state matrix
* web impl
* collapse to single method and handover branching to sql
* dedupe
* verify that owned, shared, and notShared counts are mapped independently from their respective queries
* refactor(server): add select:['id'] overload to albumRepository.getAll
Avoid fetching full album rows (with albumUsers/sharedLinks subqueries) in map.service where only album IDs are needed.
* focus relevant test filters
* fmt
* Revert "verify that owned, shared, and notShared counts are mapped independently from their respective queries"
This reverts commit 47aab458192c766de4662aada5a6841b091d2a80.
* sync sql
* Revert "document tri-state matrix"
This reverts commit a5b2355d0c.
* address review comments
* inline shared condition and return as ternary
* sync sql
* use [...albums].sort
Array.toSorted() is not supported in Chrome 109
* use isShared and isOwned nomenclature
* fix e2e tests
* add params to sql query
* fix(mobile): view similar defaults to images only
* fix(mobile): reset filter chips when pre-filter is applied
---------
Co-authored-by: shenlong <139912620+shenlong-tanwen@users.noreply.github.com>
* refactor: app metadata
* refactor to per row store
* cleanup
* more test
* review changes
* more refactor
* refactor
---------
Co-authored-by: shenlong-tanwen <139912620+shalong-tanwen@users.noreply.github.com>