Anzeige von NaN bei den Daten im Tab „Hintergrundaufgaben“

Hallo,
Ich habe seit einiger Zeit Folgendes in den Logs.

2022-12-18T11:47:00+0100 <info> scene.checkCalendarTriggers.js:24 (SceneManager.checkCalendarTriggers) Checking calendar triggers at Sun, 18 Dec 2022 10:47:00 GMT
2022-12-18T11:48:00+0100 <info> scene.checkCalendarTriggers.js:24 (SceneManager.checkCalendarTriggers) Checking calendar triggers at Sun, 18 Dec 2022 10:48:00 GMT
2022-12-18T11:49:00+0100 <info> scene.checkCalendarTriggers.js:24 (SceneManager.checkCalendarTriggers) Checking calendar triggers at Sun, 18 Dec 2022 10:49:00 GMT
2022-12-18T11:50:00+0100 <info> scene.checkCalendarTriggers.js:24 (SceneManager.checkCalendarTriggers) Checking calendar triggers at Sun, 18 Dec 2022 10:50:00 GMT
2022-12-18T11:51:00+0100 <info> scene.checkCalendarTriggers.js:24 (SceneManager.checkCalendarTriggers) Checking calendar triggers at Sun, 18 Dec 2022 10:51:00 GMT

Weiß jemand, woher das kommen könnte?
Ich habe keine Szene, die mit einem Kalender läuft, und keinen Kalender konfiguriert.

Anderes:


Ich verstehe nicht, warum es nie ein „Ausführungsdatum“ gibt.

Außerdem gibt es nur ein „g“ bei Aggregation.

Das ist ein normales Log, es ist einfach Gladys, die überprüft, ob du Szenen mit einem Kalender hast.

Es gibt nichts zu tun :slight_smile:

Das ist verrückt, diesen Bug haben wir bei einigen Nutzern schon mehrmals gesehen, aber es ist unmöglich, ihn zu reproduzieren.

Könntest du die Logs deines Browsers, Reiter « Netzwerk », anschauen und mir das Ergebnis des API-Aufrufs GET /api/v1/job?take=15&skip=0 zeigen? :slight_smile:

Tatsächlich scheinen beide Schreibweisen zu existieren (deshalb korrigieren die Rechtschreibprüfungen es nicht), aber die Form mit zwei g wird anscheinend nicht mehr verwendet ^^

Ich habe etwas gelernt!

Ich werde das korrigieren

Ich habe das gleiche Problem

Ich denke, das ist es:

[{"id":"2e1faf4f-83c4-4ea8-a2e4-807bf84617fa","type":"monthly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 15:02:25.401 +00:00","updated_at":"2022-12-19 15:02:30.859 +00:00"},{"id":"d3398f75-218c-4adf-8154-25ba019bfcb7","type":"daily-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 15:02:19.655 +00:00","updated_at":"2022-12-19 15:02:25.392 +00:00"},{"id":"d70fbd61-f4f7-43e8-abe2-16d4fdd522c3","type":"hourly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 15:02:12.794 +00:00","updated_at":"2022-12-19 15:02:19.645 +00:00"},{"id":"ae56e6a0-b9ba-40eb-906f-67ae4c862106","type":"monthly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 14:02:26.049 +00:00","updated_at":"2022-12-19 14:02:32.108 +00:00"},{"id":"4197d1c2-e3d7-4205-96e1-e914316f15b3","type":"daily-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 14:02:20.121 +00:00","updated_at":"2022-12-19 14:02:26.040 +00:00"},{"id":"b3d84ceb-2b95-43af-ac7e-f82d823a5767","type":"hourly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 14:02:12.793 +00:00","updated_at":"2022-12-19 14:02:20.112 +00:00"},{"id":"632fca35-d94d-4986-a70c-82413d29b874","type":"monthly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 13:02:24.973 +00:00","updated_at":"2022-12-19 13:02:30.384 +00:00"},{"id":"1dc49208-ab7e-4435-9b10-42e1c8a64b01","type":"daily-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 13:02:19.720 +00:00","updated_at":"2022-12-19 13:02:24.964 +00:00"},{"id":"ae611a59-a255-4382-b21a-3cf9474b28b9","type":"hourly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 13:02:12.792 +00:00","updated_at":"2022-12-19 13:02:19.711 +00:00"},{"id":"b165e458-5c34-4ac6-bcd7-9c15c53177b8","type":"monthly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 12:02:22.755 +00:00","updated_at":"2022-12-19 12:02:28.409 +00:00"},{"id":"8b198299-0298-4d8c-8f32-db7009e4b0b4","type":"daily-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 12:02:17.848 +00:00","updated_at":"2022-12-19 12:02:22.747 +00:00"},{"id":"218b89e7-a17e-4b69-95fa-a9a51d46628e","type":"hourly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 12:02:12.791 +00:00","updated_at":"2022-12-19 12:02:17.833 +00:00"},{"id":"368e2e9b-2891-4c92-8dfc-9758cef7aff6","type":"monthly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 11:02:23.096 +00:00","updated_at":"2022-12-19 11:02:28.552 +00:00"},{"id":"7d7cd4f4-1bc0-4820-85f0-679df43ed539","type":"daily-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 11:02:18.213 +00:00","updated_at":"2022-12-19 11:02:23.087 +00:00"},{"id":"519a7c51-752b-4bb1-8acc-ad506e50ed14","type":"hourly-device-state-aggregate","status":"success","progress":99,"data":{},"created_at":"2022-12-19 11:02:12.789 +00:00","updated_at":"2022-12-19 11:02:18.204 +00:00"}]

Danke für die Logs :folded_hands:

Ich halte euch auf dem Laufenden, wenn ich daran arbeite.

Danke für den Auszug, ich habe es gerade bei mir getestet und kann es nicht reproduzieren! :confused:

Ich habe mir den Code angesehen und sehe wirklich nicht, was diesen Bug verursachen könnte…

Ein paar Fragen:

  • Ihr seid wirklich auf der neuesten Gladys-Version und nicht auf einer geforkten Version? (Gladys Assistant >= v4.13.2)
  • Auf einem unterstützten Browser (Firefox, Chrome, Safari)?
  • Gladys lokal oder Gladys Plus?
  • Habt ihr im privaten Modus getestet (nur um zu überprüfen, ob es nicht ein Cache-Bug einer alten Frontend-Version ist)?
  • Tritt der Bug 100% der Zeit oder zufällig auf?

Wir werden es herausfinden!

Ja (heute Morgen aktualisiert)

Firefox und Safari nicht OK
Chrome/Brave OK

Gladys lokal (von mehreren Geräten zu Hause aus: mobile/mac/iPad)

Ja, gleiches Verhalten

Schwer zu sagen. Ich würde sagen 100% der Zeit auf demselben Browser/Gerät.
Ich dachte an ein Problem mit der Browsersprache, aber ich habe es ohne Erfolg getestet.

Ich werde etwas Debugging im Frontend-JS im Entwicklermodus machen und ergänzen.
Mach dir keine Mühe, für mich ist es ein kleiner Bug.

Das ist ja interessant!

Okay, halte mich auf dem Laufenden.

Ist trotzdem ein bisschen eklig, wir müssen das finden, das wirkt nicht seriös ^^

Ich bestätige auch, dass es bei mir unter Chrome OK ist und Firefox nicht.

Ich kann es auch reproduzieren, ich habe den Bug verstanden :grin: Das Parsen dieses Datumsformats funktioniert unter Chrome, aber nicht unter Safari oder Firefox

Wir sollten zu einem klassischeren Format wechseln, das von allen Browsern gelesen werden kann, das kann auf der Frontend-Seite gemacht werden ^^

@cicoub13 falls du Lust hast, eine kleine PR zu machen, sonst mache ich es :grinning_face_with_smiling_eyes:

Also habe ich einen Blick darauf geworfen und brauche vor der Korrektur eine Meinung.
Laut der Dokumentation von dayjs akzeptiert die Bibliothek nur das Parsen von Datumsangaben im ISO3601-Format 2018-04-13 19:18:17.040+02:00

Aber die Datumsangaben der Jobs werden in diesem Format YYYY-MM-DD HH:mm:ss.SSS Z (wie 2023-01-20 20:39:46.089 +00:00) mit einem Leerzeichen gespeichert.

Ich habe keine Ahnung, warum Chrome und Safari funktionieren und Firefox nicht :man_shrugging:

Es gibt mehrere Lösungen:

  • Die Art und Weise, wie wir die Datumsangaben in der Datenbank speichern, ändern, um dem ISO3601-Format zu entsprechen. Aufwendig und unsicher bezüglich der Auswirkungen anderswo
  • Die Daten bei der Abfrage der Job-Objekte in settings-background-jobs/index.js umwandeln
  • Die Komponente RelativeTime ändern, um das benutzerdefinierte Format beim Parsen anzugeben

let relativeTime = dayjs(datetime, 'YYYY-MM-DD HH:mm:ss.SSS Z');

Genau diese letzte Lösung schlage ich in einem PR hier vor
Es funktioniert für die Jobs-Seite, aber :warning: die Komponente wird auch für Sensoren verwendet.

Der Datumsparser von Chrome ist flexibler :slight_smile: dayjs ist nur eine Hülle um new Date(), wenn du auf jedem Browser vergleichst, akzeptiert Chrome Formate, die andere nicht akzeptieren.

Ich wäre eher für diese Option!

Die Komponente RelativeTime wird an vielen Stellen verwendet, und ich denke nicht, dass es wünschenswert ist, dass das Standardverhalten dieser Komponente darin besteht, nur Datumsangaben im nicht standardisierten String-Format zu akzeptieren.

Aktuell ist der Vorteil dieser Komponente, dass sie auch JS-Datumsangaben als Parameter akzeptiert.

Danke für den PR @cicoub13 :pray:

Ich bin für die Umstellung bereit, aber Achtung, dein PR behandelt nicht alle Fälle, insbesondere die Hinzufügung/Aktualisierung von Jobs über WebSockets :slight_smile:

OK, ich schau mir das nochmal an, ich bin eingerostet :blush: