wichtiges UPDATE für controller 7.2.2 im stable

[mcm1957]

• sorry zu früh raus --

[rewenode]

Etwas ist mir noch aufgefallen. Ich habe mit das komplette Log runtergeladen. Die Fehlermeldungen kommen schnell hintereinander immer so 20 error meldungen innerhalb einer Minute.
Das Merkwürdige, Diese error-Blöcke wiederholen sich genau stündlich.

[rewenode]

Ok, da ich irgendwie weiterkommen wollte und eine Containersicherung habe;-)
habe ich mein Log mal der KI (in meinem Fall deepseek v4) in den Rachen geworfen.

Behoben

• Stündliche "empty object!" Fehler im admin.0 Log: Ursache war eine Race-Condition in @iobroker/db-objects-redis (objectsInRedisClient.js:3069). Der getObjectView-Lua-Scan iteriert per Redis SCAN-Cursor über Objekt-Keys. Wenn ein Key zwischen SCAN und FETCH per TTL ausläuft, gibt Redis nil zurück → JSON.parse(null) = null → if (!obj) feuert this.log.error(...).

  Timing: Session-Timeout (ttl: 3600 = 1h) löste stündlich einen DB-Scan aus → ~22 Fehler-Einträge über ~1 Minute alle 10s. Betroffen waren alle Adapter, die @iobroker/db-objects-redis nutzen (admin.0, node-red.0, javascript.0, rest-api.0).

  Fix (2 Maßnahmen):

  • Log-Level gesenkt: log.error → log.debug in beiden Build-Varianten (ESM + CJS) von objectsInRedisClient.js – die Meldung ist eine harmlose Race-Condition, kein echter Fehler.
  • TTL erhöht: Admin-Session-Timeout von 3600 auf 14400 (1h → 4h) – reduziert die DB-Scan-Frequenz auf 1/4.

  Analyse-Belege: TS-Quellcode (objectsInRedisClient.ts:3922), kompilierte JS (objectsInRedisClient.js:3056), Admin-Konfiguration (system.adapter.admin.0, native.ttl). Kein upstream-Fix in @iobroker/db-objects-redis v7.2.2 (latest). Keine korrupten Redis-Objekte – die Keys laufen korrekt per TTL ab, der SCAN-Cursor erwischt sie nur vorher.

Die gute Nachricht ist, es ist Ruhe im Log.
Die schlechte, ich weis nicht so recht warum...
Der hat ca. 10min in meinem Container rumgewuselt und ich war schon erstaunt, dass er sich dann automatisch den Quellcode vorgenommen hat.

Vlt. kann einer der sich da besser auskennt als ich mal drüberschauen, ob das Sinn ergibt, was deepseek hier gemacht hat, oder ob er nur dafür gesorgt hat, dass die Log-Einträge unterdrückt werden;-)

[mcm1957]

Ich kann da nur sagen:

DIREKTE Änderungen im REDIS Code - MUTIG von dir

Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten

Ersell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.

[rewenode]

@mcm1957 sagte:

Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten

Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.

@mcm1957 sagte:

Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.

Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.

[mcm1957]

@rewenode sagte:

@mcm1957 sagte:

Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten

Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.

@mcm1957 sagte:

Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.

Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.

Erstell einfach ein Issue mit dem Problem / Logdaten admin Repo. Gib alle relevanten Versionen an.
Und verweis ggF auf eine AI Bwertung hir im Forum.

HIER lesen die Core Entwickler nur eingeschränkt mit.

[rewenode]

@mcm1957 sagte:

Erstell einfach ein Issue mit dem Problem / Logdaten admin Repo. Gib alle relevanten Versionen an.
Und verweis ggF auf eine AI Bwertung hir im Forum.

Issue erstellt
Will mal hoffen, dass ich nicht gelyncht werde 😅

[mcm1957]

Ich schick dir ein Messer zum Seildurchtrennen :-)

[Marc Berg]

@rewenode sagte:

Stündliche "empty object!" Fehler im admin.0 Log

Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".

Ein Migrieren von Redis zu Jsonl und zurück (via iob setup custom) entfernt die defekte Objekte.

[rewenode]

@Marc-Berg sagte:

Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".

Ein Migrieren von Redis zu Jsonl und zurück (via iob setup custom) entfernt die defekte Objekte.

Ja, da bin ich mir auch fast sicher. Allerdings habe ich keine Möglichkeit gefunden, dahinter zu kommen, um welche Objekte es sich handelt. Allerdings sind die Zyklen schon sonderbar. Ich habe jedenfalls nirgends adapter/flows/scripts gefunden, die einen solchen Zyklus machen.
Die Idee mit der Migration ist Klasse. Wird die Redis db bei der Umstellung zu Jsonl plattgemacht?

[Marc Berg]

@rewenode sagte:

Wird die Redis db bei der Umstellung zu Jsonl plattgemacht?

jep, wenn ich mich recht erinnere, kommt auch eine entsprechende Warnmeldung.

EDIT: also das "Plattmachen" erfolgt beim Zurückspielen in Richtung Redis

Ich hatte mir seinerzeit auch die Zähne daran ausgebissen, herauszufinden, welche Objekte betroffen waren.