* feat(server): remove deprecated password field from update-me
* fix: tests for removed password field
(cherry picked from commit 3f6a071203187681b6c06b977665dc624c431336)
asset_face, stack and workflow were the only tables with an updateId
column but no index on it. Face and stack sync (AssetFacesV1/V2,
StacksV1, PartnerStacksV1) filter and order on updateId, so every mobile
sync seq-scanned every face on the instance and walked all of the user's
(or partners') stacks, even when nothing had changed. workflow isn't
synced; it gets the index for consistency.
Incremental sync with nothing changed, PG 14:
| query | before | after |
| ---------------------------------- | -------- | -------- |
| assetFace.getUpserts (425k faces) | 33-37 ms | 0.15 ms |
| stack.getUpserts (6k stacks) | 0.8 ms | 0.004 ms |
| partnerStack.getUpserts (6k) | 0.6 ms | 0.007 ms |
The face scan grows with the instance's face count (~10x that at 4M
faces); the stack one with the user's stack count.
(cherry picked from commit 9df807ed4a9536a28dad463270082095ec1fe94d)
* fix(server): require upload access for checksum duplicate check
* fix(server): use the upload access check for the checksum short circuit
(cherry picked from commit 5c02b17495947d7332cce13273226082bd8ae2a1)
SharedLinkRepository.get (shared link page load, /shared-links/me, and the
OpenGraph tags rendered for /share/:key) json_agg'd every asset of the
album, with its full exif row, ordered by fileCreatedAt. The only things
used from it are the asset count and the first/last localDateTime.
Load the album without assets and fill assetCount/startDate/endDate from
getMetadataForIds, which is what GET /albums/:id already uses. The counts
now also respect the default visibility filter, and the dates are
formatted the same as on /albums/:id.
150k-asset album link, PG 14:
| | before | after |
|------------------------|-----------------|--------|
| query | 4.2-6.5 s | ~0.26 s (metadata aggregate) |
| JSON built by postgres | 261 MB | - |
| GET /shared-links/me | - | 0.28 s, 961 B |
(cherry picked from commit ac453b5557e42ad45962d3079a4e4450671053e9)
* perf(server): stop loading every album asset to build album responses
Album create, update (rename, description, cover, sort order, activity
toggle) and add-users json_agg'd every asset of the album with its exif
row, only for mapAlbum to read the count and the first/last
localDateTime. Use getMetadataForIds for those fields, as GET /albums/:id
already does, and drop the now unused withAssets option from getById.
The responses now carry the same date format and lastModifiedAssetTimestamp
as GET /albums/:id.
PATCH /albums/:id on a 150k-asset album, PG 14 (response is ~900 B either
way): 3.4-3.6 s -> 0.13-0.16 s.
* refactor(server): share album metadata mapping
(cherry picked from commit 2a4e876ec990a4a8d5fdca00291cbeebd3d1bccf)
* perf(server): check shared link asset access without scanning the album
checkSharedLinkAccess runs on every thumbnail, preview, playback and asset
info request made through a shared link. It joined every asset of the
link's album and only then filtered on an array overlap across four
outer-joined columns, so each request cost O(album size).
Split it into two branches (link assets, album assets) that find the
requested ids through the asset pkey / livePhotoVideoId index and then
probe the album_asset pkey.
Median per request, PG 14, 1.36M-asset instance:
| album behind the link | before | after |
|-----------------------|--------|---------|
| 290 assets | 2.1 ms | 0.17 ms |
| 150k assets | 296 ms | 0.19 ms |
* chore: clean up
---------
Co-authored-by: Jason Rasmussen <jason@rasm.me>
(cherry picked from commit bb024c862609c9e2baffc08fef795cfa3418df16)
Hopefully this stops people from just dropping "n/a" when they're using an unsupported deployment
(cherry picked from commit 5380498debd853191d46a8cf5322778d0c0d1b5c)
* fix: throw a typed error on malformed api responses
* fix: drop response body parse check
* fix(web): keep json response validation when overriding fetch (#31008)
* fix(cli): report malformed api responses (#31007)
The alpine suffix part wasn't getting updated by renovate, and the 3.20
chain stopped getting node updates too. This also just aligns the base
image distro with what we use elsewere.
This waits for up to 2 min to group up to 3 PRs into the same draft. That should cut down on the amount of draft PRs that get created. The main downsides are the 2 minute wait when only queueing one PR, and less failure isolation: on an error, mergify has to do bisect runs to figure out which PR failed the batch, which takes more time than purely sequential operation. All of this can be tuned further of course.
* fix: always set extension from provided file
The livephoto case can also happen with other files; for example, we
receive a DNG file as JPEG but then still call it .dng
Fixes#29805, partially addresses #28602
* chore: test cases for file extension naming
