- Verschifft
- 26. August 2026 um 20:42 UTC
- Autor
- kamo
- Ausschuss
- 9cf27f5
Eine neue Organisation mit Logo, Farben und drei Hintergründen wurde gegründet. Alle davon korrekt in die Öffentlichkeit/wiederschnitzel/ - 15 Objekte, rechts hex-Werte in globals.css, config.json, die drei Hintergründe benennt. Die Registerkarte noch geöffnet trägt Kamo's Branding. Der Grund war hier, im Pod-Log: [org GET] alias=wienerschnitzel ************************************************ [org fetch] GET **************** [rery] org err='fetch failed' isAbort=false willRetryIn=250ms [rery] org scheiterte nach 804ms Versuchen=3 [TypeError: holen gescheitert] [org GET] fertig Status=200 Features=10 Diese Route baute ihre vorgelagerte Basis als "Api.<path segment". Das funktionierte während jedes Segment war ein Hostname; ?org=" trägt eine Organisation REFERENCE jetzt ID oder ein Web-Alias - so fragte es einen Host, der nicht existiert. Drei Dinge, von denen jedes unabhängig genug war, um dies zu verursachen: - Der API-Host kommt von dem Host THIS Anfrage angekommen. Der Browser bereits aufgelöst innen.<apex? hierher zu kommen, so api.<same Pech ist bekannt, dass zu existieren was auch immer die Referenznamen. Es schließt auch ein Loch, das nur erreichbar wurde nachdem die Referenz aufgehört hat, ein Hostname zu sein: ein handwerklicher ?org= hat ausgewählt, welcher Host Dieser Server hat das Session-Cookie des Anrufers an gesendet. - Eine Referenz geht an /org/ref, ein Hostname zu /org/domain. Nur ersteres kann Antwort für eine Organisation ohne Host, die die meisten von ihnen jetzt ist. - Ein fehlgeschlagener Lookup antwortet 404, nicht 200 mit einem fabrizierten KamoCRM-Rekord. Das fallback - rechte ID, ist TopLevel, zehn Features - ist der Grund, warum die Shell nicht sagen konnte "Dies ist Ihre Organisation" von "Ich konnte den Server nicht erreichen", und warum es behandelte die Plattform als NAMED-Pächter der Registerkarte. OrgUrlSync hätte dann diese Antwort in die URL für jede spätere Anfrage von der Registerkarte gepinnt. fetchOrganization behandelt bereits einen 404: es fällt zurück auf den Host und zeichnet auf viaRef=false, so bleibt der Fallback unauffällig, was der springende Punkt ist. Die Routing-Logik bewegte sich auf App/lib, so dass es tatsächlich getestet werden kann - app/api/** ist nicht in vitest's enthaltene Genehmigungsliste, so dass ein Test neben der Route bestanden hätte indem Sie nie laufen.