Immich: handle mise monorepo_root rename correctly | bump to 3.0.1

[MickLesk]

✍️ Description

The change ensure that monorepo_root = true is present while retaining experimental_monorepo_root = true, so plugin builds work across old and new mise versions after the v2026.7.0 key rename

added tools.func bugfixing due pnpm issues - in setup_nodejs, all variants now fall back to npm install -g --force when the normal install fails. --force is npm's own recommended resolution for this EEXIST

🔗 Related Issue

Fixes #15153
Fixes #15556
Fixes #15555

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to script metadata (PocketBase/website data).
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

[MickLesk]

Draft due reverted 3.0.0 Branch for now

[vhsdream]

Honestly I have no idea why this failed for everyone except me, aside from the fact that I only do this so that my Immich works and I don't know how to come up with a way of testing many different possibilities. I can't control for others failing to maintain their LXCs and fucking up their environments. I never had to manually install extism-js - it gets installed when running the mise commands in the sequence that's already in the script. Or at least it should. It's clear I've messed up somewhere.

I don't understand why there were 'monorepo' failures or why all of these additions/workarounds are necessary, and frankly I no longer have the time or inclination to find out quickly enough. I don't use LLMs for coding/programming and I'm not actually a coder, it's just one of my special interests.

This is a lot of complaining and whining, but what I'm working up to is I want to say I really appreciate you @MickLesk for being so dedicated to this entire project and for stepping up your work on Immich over the past few months, especially as it's becoming increasingly clear I've lost my grasp on the script. I really wish I could contribute more, but life is hard right now so I have a lot less time to do this.

Oh! and also, I approve these changes because they seem to work, even if you are on v3.0.0.

[MickLesk]

Dont merge yet, i forgot something, cant Put Back into draft on mobile App @community-scripts/contributor

[MickLesk]

done

[MickLesk]

Honestly I have no idea why this failed for everyone except me, aside from the fact that I only do this so that my Immich works and I don't know how to come up with a way of testing many different possibilities. I can't control for others failing to maintain their LXCs and fucking up their environments. I never had to manually install extism-js - it gets installed when running the mise commands in the sequence that's already in the script. Or at least it should. It's clear I've messed up somewhere.

I don't understand why there were 'monorepo' failures or why all of these additions/workarounds are necessary, and frankly I no longer have the time or inclination to find out quickly enough. I don't use LLMs for coding/programming and I'm not actually a coder, it's just one of my special interests.

This is a lot of complaining and whining, but what I'm working up to is I want to say I really appreciate you @MickLesk for being so dedicated to this entire project and for stepping up your work on Immich over the past few months, especially as it's becoming increasingly clear I've lost my grasp on the script. I really wish I could contribute more, but life is hard right now so I have a lot less time to do this.

Oh! and also, I approve these changes because they seem to work, even if you are on v3.0.0.

Everything's fine—it was a struggle. I'd hoped to get it sorted out yesterday, but unfortunately it felt like every user was having different issues. That's why I added a few more fallbacks. In the end, though, it finally seems to be working. In Germany, we call it a "Eierlegende Wollmilchsau (“jack-of-all-trades”) —thanks for your effort; it’s really scary what it takes—these days—to get immich running :/ Everyone would have been spared all that unnecessary Mise and pnpm stuff if there were decent prebuilds available.

[maxxie85]

Honestly I have no idea why this failed for everyone except me, aside from the fact that I only do this so that my Immich works and I don't know how to come up with a way of testing many different possibilities. I can't control for others failing to maintain their LXCs and fucking up their environments. I never had to manually install extism-js - it gets installed when running the mise commands in the sequence that's already in the script. Or at least it should. It's clear I've messed up somewhere.

I don't understand why there were 'monorepo' failures or why all of these additions/workarounds are necessary, and frankly I no longer have the time or inclination to find out quickly enough. I don't use LLMs for coding/programming and I'm not actually a coder, it's just one of my special interests.

This is a lot of complaining and whining, but what I'm working up to is I want to say I really appreciate you @MickLesk for being so dedicated to this entire project and for stepping up your work on Immich over the past few months, especially as it's becoming increasingly clear I've lost my grasp on the script. I really wish I could contribute more, but life is hard right now so I have a lot less time to do this.

Oh! and also, I approve these changes because they seem to work, even if you are on v3.0.0.

People always complain on failure. It's the easy way out.
However, if it wasn't for your effort they wouldn't have anything to complain about.
It's not your responsibility for their failure of maintaining an LXC and attempting to use this that might be over their head.
They learn, and unfortunately shout in frustration.

For me hoewever, I have nothing but praise for your efforts and hours to get this to work. So I'm only grateful. And if I can will help out.

[N1V4K]

Hello Mick,

I got this error if i want to update, any idea?

`REINDEX
INFO:  clustering: estimated memory usage is 1.13 GiB
ERROR:  missing chunk number 1 for toast value 1286153 in pg_toast_17332
  ✖️  in line 135: exit code 1 (General error / Operation not permitted): while executing command  sudo -u postgres psql -d immich -c "REINDEX INDEX clip_index;"

  --- Last 20 lines of log ---
[2026-07-03 23:12:51] [INFO] Installing/upgrading Testing repo packages
[2026-07-03 23:12:52] [OK] Installed/upgraded Testing repo packages
[2026-07-03 23:12:52] [WARN] Checking for updates to custom image-processing libraries (recompile time: 2-15min per library)
[2026-07-03 23:12:53] [INFO] Recompiling libvips
[2026-07-03 23:13:20] [OK] Recompiled libvips
[2026-07-03 23:13:20] [OK] Image-processing libraries up to date
[2026-07-03 23:13:20] [INFO] Checking for update: Immich
[2026-07-03 23:13:20] [OK] Update available: Immich 2.7.5 → 3.0.1
[2026-07-03 23:13:20] [INFO] Enabling Maintenance Mode
[2026-07-03 23:13:22] [OK] Enabled Maintenance Mode
[2026-07-03 23:13:22] [INFO] Stopping Services
[2026-07-03 23:13:22] [OK] Stopped Services
[2026-07-03 23:13:22] [INFO] Checking for update: VectorChord
[2026-07-03 23:13:23] [OK] Update available: VectorChord 0.5.3 → 1.0.0
[2026-07-03 23:13:23] [INFO] Fetching GitHub release: VectorChord (1.0.0)
[2026-07-03 23:13:27] [OK] Deployed: VectorChord (1.0.0)
[2026-07-03 23:13:44] [ERROR] in line 135: exit code 1 (General error / Operation not permitted): while executing command  sudo -u postgres psql -d immich -c "REINDEX INDEX clip_index;"
  -----------------------------------

 📋 Full log: /tmp/create-lxc-802d9408.log`

[MickLesk]

Your DB is broken (before the Update), so you need to restore and Investigate why the Indexes are broken. Thats not related to Script or update (chunks broken)

[N1V4K]

Your DB is broken (before the Update), so you need to restore and Investigate why the Indexes are broken. Thats not related to Script or update (chunks broken)

Thanks, you were right — the issue was already in the database before the update and was not caused by the script/update itself.

I checked which table the broken TOAST table belonged to, and it pointed to smart_search. I then rebuilt the TOAST table/indexes and successfully ran:

REINDEX INDEX clip_index;

The reindex completed without errors, so the issue is resolved now.

Sorry for posting it here so quickly before digging further myself. Thanks Mick for pointing me in the right direction.

[bradyjoh]

@N1V4K I also had the exact same issue for the first time ever when trying to update. Same thing happened after reverting to a snapshot. Can you provide more detail on how you fixed it?

Edit: I went to Administration > Job Status > Smart Search job, and clicked "All" to reprocess. That seems to have fixed the issue for me, as the update script then completed successfully

[N1V4K]

@N1V4K I also had the exact same issue for the first time ever when trying to update. Same thing happened after reverting to a snapshot. Can you provide more detail on how you fixed it?

Edit: I went to Administration > Job Status > Smart Search job, and clicked "All" to reprocess. That seems to have fixed the issue for me, as the update script then completed successfully

Hi,

I am not at home at this moment. I send it you later today

[irishpadres]

For anyone landing here from the missing chunk ... for toast value ... in pg_toast_* / REINDEX INDEX clip_index failure during the 3.0.1 update — I dug into this in #15588 and it turned out not to be DB corruption, but a VectorChord 1.0.0 reindex issue triggered by dead tuples in smart_search/face_search. Details and a workaround here: #15588 (comment)

It might be worth having the script check n_dead_tup on those two tables (via pg_stat_user_tables) before the VectorChord bump, and run a VACUUM only if it's nonzero. Could catch some of these failures automatically without adding vacuum time to installs that don't need it.

Also worth noting why re-running Smart Search (as suggested above) works too: it rewrites the smart_search table, which clears the dead tuples as a side effect — same fix, different route. It's a valid option, but it re-runs CLIP inference on every asset, so it scales with library size. For reference, on my library it took over 24 hours to finish, whereas the VACUUM above is a matter of seconds regardless of library size.