WebUI exception when deleting not yet created new album #7771

Open
opened 2026-02-05 13:17:54 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @igorrust on GitHub (Nov 7, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

In the WebUI version, when I create a new album, but then delete this (not yet) created album, an exception is generated. I would imagine the Delete-option would not be available in the first place.

Image

The OS that Immich Server is running on

Ununbtu 22

Version of Immich Server

v2.2.3

Version of Immich Mobile App

n/a

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

Windows 11

Your docker-compose.yml content

n/a

Your .env content

n/a

Reproduction steps

  1. Navigate to Albums, and click on Create album
  2. Click in the right-top corner on the menu icon, and click Delete album
  3. Click Confirm in the modal.
  4. An exception is shown: [handleError]: Unable to delete album Error: Error: 400 ( the Delete call gives a 400 http response).
  5. Pressing the Back button in the WebUI (left-top corner) will send the Delete - backend call again and again.

You need to reload the page to continue working with Immich.

Relevant log output

[handleError]: Unable to delete album Error: Error: 400

Additional information

No response

Originally created by @igorrust on GitHub (Nov 7, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug In the WebUI version, when I create a new album, but then delete this (not yet) created album, an exception is generated. I would imagine the Delete-option would not be available in the first place. <img width="1330" height="878" alt="Image" src="https://github.com/user-attachments/assets/04bf6524-7219-41c5-9993-542873841f8e" /> ### The OS that Immich Server is running on Ununbtu 22 ### Version of Immich Server v2.2.3 ### Version of Immich Mobile App n/a ### Platform with the issue - [ ] Server - [x] Web - [ ] Mobile ### Device make and model Windows 11 ### Your docker-compose.yml content ```YAML n/a ``` ### Your .env content ```Shell n/a ``` ### Reproduction steps 1. Navigate to **Albums**, and click on **Create album** 2. Click in the right-top corner on the menu icon, and click **Delete album** 3. Click **Confirm** in the modal. 4. An exception is shown: `[handleError]: Unable to delete album Error: Error: 400` ( the Delete call gives a `400` http response). 5. Pressing the Back button in the WebUI (left-top corner) will send the Delete - backend call again and again. You need to reload the page to continue working with Immich. ### Relevant log output ```shell [handleError]: Unable to delete album Error: Error: 400 ``` ### Additional information _No response_
Author
Owner

@meesfrensel commented on GitHub (Nov 7, 2025):

A little investigation shows that the deleteAlbum endpoint is being called twice. My guess is that after deleting the album in L249 below, the goto referenced in L250 below causes the onNavigate to trigger, which also attempts to delete the album if it's completely empty. That order doesn't really work for surfacing the error though, as that's only handled in the first call... Not sure what's going on.

6913697ad1/web/src/routes/(user)/albums/%5BalbumId%3Did%5D/%5B%5Bphotos%3Dphotos%5D%5D/%5B%5BassetId%3Did%5D%5D/%2Bpage.svelte#L240-L256

6913697ad1/web/src/routes/(user)/albums/%5BalbumId%3Did%5D/%5B%5Bphotos%3Dphotos%5D%5D/%5B%5BassetId%3Did%5D%5D/%2Bpage.svelte#L306-L310

FYI, the same happens when navigating back to albums with the back button, but the error isn't surfaced to the user (and I think the first call would in this case be from onNavigate, then the /albums page is loaded, then the second call to the delete endpoint is triggered).

@meesfrensel commented on GitHub (Nov 7, 2025): A little investigation shows that the `deleteAlbum` endpoint is being called twice. My guess is that after deleting the album in L249 below, the `goto` referenced in L250 below causes the `onNavigate` to trigger, which also attempts to delete the album if it's completely empty. That order doesn't really work for surfacing the error though, as that's only handled in the first call... Not sure what's going on. https://github.com/immich-app/immich/blob/6913697ad15b3fcad80fc136ecf710af19d1f5df/web/src/routes/(user)/albums/%5BalbumId%3Did%5D/%5B%5Bphotos%3Dphotos%5D%5D/%5B%5BassetId%3Did%5D%5D/%2Bpage.svelte#L240-L256 https://github.com/immich-app/immich/blob/6913697ad15b3fcad80fc136ecf710af19d1f5df/web/src/routes/(user)/albums/%5BalbumId%3Did%5D/%5B%5Bphotos%3Dphotos%5D%5D/%5B%5BassetId%3Did%5D%5D/%2Bpage.svelte#L306-L310 FYI, the same happens when navigating back to albums with the back button, but the error isn't surfaced to the user (and I think the first call would in this case be from `onNavigate`, then the /albums page is loaded, _then_ the second call to the delete endpoint is triggered).
Author
Owner

@Snowknight26 commented on GitHub (Nov 12, 2025):

After https://github.com/immich-app/immich/pull/23773, step 5 of your repro steps no longer applies since failing to delete the album the second time doesn't leave immich in a bad state. You're now back on the album list and things work as expected (extra toast aside).

I don't think there's an easy way to solve this because of the current rules in place (delete the album if it has no name and no assets).

If the code is changed so that we keep track of whether the manual "delete" action was used, in an attempt to not delete the album again on navigate, we'll run into a scenario where not attempting to delete the album and simply navigating away to the album list will 1) attempt to delete the album from the album page (in onNavigate, which can be async) and 2) attempt to delete all empty albums from the album list (via removeAlbumsIfEmpty in onMount), which can fail due to race conditions.. meaning you'll still see the failed delete toast.

Seems like we shouldn't be deleting empty albums. If the concern is that empty albums will eventually make their way into various parts of the UI without names, maybe the best thing to do is to add a default name ("New album" or something). If the concern is that the UI isn't reactive enough to make it obvious that an album was created, maybe that can be tackled too.

@Snowknight26 commented on GitHub (Nov 12, 2025): After https://github.com/immich-app/immich/pull/23773, step 5 of your repro steps no longer applies since failing to delete the album the second time doesn't leave immich in a bad state. You're now back on the album list and things work as expected (extra toast aside). I don't think there's an easy way to solve this because of the current rules in place (delete the album if it has no name and no assets). If the code is changed so that we keep track of whether the manual "delete" action was used, in an attempt to not delete the album again on navigate, we'll run into a scenario where _not_ attempting to delete the album and simply navigating away to the album list will 1) attempt to delete the album from the album page (in `onNavigate`, which can be `async`) and 2) attempt to delete all empty albums from the album list (via `removeAlbumsIfEmpty` in `onMount`), which can fail due to race conditions.. meaning you'll still see the failed delete toast. Seems like we shouldn't be deleting empty albums. If the concern is that empty albums will eventually make their way into various parts of the UI without names, maybe the best thing to do is to add a default name ("New album" or something). If the concern is that the UI isn't reactive enough to make it obvious that an album was created, maybe that can be tackled too.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#7771