fix(favorite): avoid 500 when unfavoriting a note with no tags left (#554)

removeFromFavorites() can leave a note with no tags, in which case
getTagsForObjects([$id]) returns an array without the $id key. Reading
$tags[$id] then yields null, and in_array() throws a TypeError, so the
PUT .../favorite request returns HTTP 500 even though the state change
was already persisted.

Guard the lookup with array_key_exists(), matching the defensive pattern
already used in getAll() and getTags().

Fixes #553

Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: DeepDiver1975

CHANGELOG.md

@@ -7,6 +7,11 @@
   instead of a blank white area.
 
 ### Fixed
+- Unfavoriting a note no longer returns HTTP 500. When a note had no tags left
+  after removing the favorite, `getTagsForObjects()` returns no entry for the
+  note id, so `in_array()` was called with `null` and threw a `TypeError`. Guard
+  the lookup with `array_key_exists()`, matching the pattern already used
+  elsewhere in `NotesService`.
 - Restore the empty AngularJS hash prefix so clicking a note in the sidebar
   opens it again. The AngularJS 1.8 upgrade changed the default hash prefix to
   `!`, which broke the `#/notes/{id}` sidebar links so only the first note (or

service/notesservice.php

@@ -181,7 +181,8 @@ public function favorite($id, $favorite, $userId) {
 		}
 
 		$tags = $tagger->getTagsForObjects([$id]);
-		return \in_array(\OC\Tags::TAG_FAVORITE, $tags[$id]);
+		$noteTags = \array_key_exists($id, $tags) ? $tags[$id] : [];
+		return \in_array(\OC\Tags::TAG_FAVORITE, $noteTags);
 	}
 
 	/**