Get Active Blueprint Job
Der Lauf, ueber den das Dashboard Bescheid wissen muss.
Damit findet es eine Erfassung oder Anwendung wieder, die es aus den Augen verloren hat: nach einem Reiterwechsel, einem Neuladen oder weil jemand von einem anderen Geraet aus gestartet hat.
── WARUM HIER AUCH EIN GESCHEITERTER LAUF HERAUSGEHT ─────────────────
Bis hierher meldete diese Route nur LEBENDE Laeufe, und ein toter wurde zu null. Das ergab die schlimmste aller Anzeigen: der Streifen war einfach weg. Verschwinden ist aber die Bewegung von FERTIG - wer sie sieht, schliesst daraus, dass es geklappt hat. Bei einer Sicherung merkt man diesen Irrtum erst an dem Tag, an dem man sie braucht.
Deshalb geht ein Lauf, der in der letzten Stunde OHNE ERGEBNIS geendet hat, hier ebenfalls hinaus. Das Frontend braucht dafuer nichts Neues: neuerer() nimmt ihn, shouldWatch sieht einen terminalen Status und pollt nicht, stripVisible zeigt den Streifen mit seinem Fehlertext.
Die Stunde ist dieselbe Spanne wie in utils/insel_live, und sie ist dort begruendet. Kuerzer verpasst man den Fehlschlag beim Kaffeeholen; laenger stuende der rote Streifen noch da, wenn die Sache erledigt ist.
── UND WARUM DIE ROUTE SELBST URTEILT ────────────────────────────────
Aufgeschrieben wird ein Fehlschlag vom Aufraeumlauf im Bot. Der sitzt IM Bot - ist der Bot aus, raeumt niemand auf, und das ist ausgerechnet der Fall, in dem ein Auftrag nicht angenommen wird. verendet() faellt das Urteil deshalb hier, ohne zu schreiben: der Datensatz bleibt, wie er ist, und der Aufraeumlauf holt ihn ein, sobald der Bot wieder da ist.
Request
- Base URL: https://api.notoq.xyz (the document declares no server; this is the origin it was published from)
- URL: https://api.notoq.xyz/api/v1/servers/{server_id}/blueprints/jobs/active
- Auth: HTTP bearer
Path parameters
Discord Server ID
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.