Ebben a cikkben
Ha egy ütemezett poszt meghiúsul, az újrapróbálkozás előtt vizsgáld meg az egyes célállomások eredményét. A hibás válasz jelentheti azt, hogy a platform elutasította a tartalmat, de egy elveszett válasz miatt a tényleges kimenetel bizonytalan is maradhat. Az Uplonic ezt a különbséget rögzíti a publikálási feladaton, és kifejezett megerősítést kér, mielőtt újra elindítana egy bizonytalan kimenetelűként (unknownOutcome) megjelölt feladatot.
Egyetlen publikálási kérés sikeres lehet az egyik hálózaton, miközben meghiúsul egy másikon. Ha ugyanazt a forrásvideót több helyre terjeszted, az egyvideós keresztposztolási munkafolyamat elmagyarázza, miért igényel minden célállomás saját beállításokat. A teljes kérés újbóli létrehozása feleslegesen megismételheti a már sikeres célállomásokat.
Mielőtt elkezded: keresd meg a pontos sikertelen kísérletet
Ez az útmutató az API-t használja. Szükséged lesz a munkaterület API alap URL-jére, egy írási jogosultsággal rendelkező API-kulcsra, a publikálási kérés azonosítójára (REQUEST_ID), valamint a vizsgálni kívánt feladatok azonosítóira (TASK_ID). Az API-kulcsot az x-api-key fejlécben küldd el, és abban a munkaterületben dolgozz, amelyhez a kérés tartozik.
Küldj egy GET /uploads/requests/REQUEST_ID kérést. Vizsgáld meg a feladat status, platform, lastErrorClass, lastErrorMessage, unknownOutcome és esetleges platformUrl mezőit. Nézd meg a szülőkérés állapotát is, de soha ne kizárólag a szülőkérés státusza alapján döntsd el, hogy mit küldesz újra.
Tesztelési hatókör: 2026. október 17-én egy dedikált fejlesztői munkaterületen, szintetikus hibás feladatokkal futtattuk le a tényleges kérésrészletező és újrapróbálkozó végpontokat. Ellenőriztük a megerősítés kezelését és a tárolt várólista-állapotváltásokat. A háttérfolyamat (worker) végrehajtását izoláltuk, így a teszt nem publikált tartalmat, nem ellenőrzött valós közösségi fiókot és nem reprodukált szolgáltatói leállást.
Válaszd szét a bizonytalan kimenetelt az ismert hibától
Ha az unknownOutcome értéke true, nyisd meg a célfiókot a közösségi platformon, és keresd meg a szándékolt bejegyzést. Ellenőrizd a fiók azonosságát, a forrástartalmat és a kísérlet hozzávetőleges időpontját. Ha megtalálod a posztot, állj meg: az újrapróbálkozás duplikációt hozhat létre. Ha nem tudod megállapítani az eredményt, őrizd meg a hiba részleteit, és tisztázd a bizonytalanságot a megerősítés előtt.
Ugyanezt az alapvető problémát tárgyalja a HTTP Semantics szabvány 9.2.2-es szakasza (ellenőrizve: 2026. október 17.): egy olyan művelet megismétlése, amelynek hatása bizonytalan, körültekintést igényel. A HTTP-státuszkód önmagában nem igazolja, hogy egy nem idempotens publikálási művelet végbement-e vagy sem.
Ha a kimenetel ismert, hárítsd el a rögzített okot. Egy inaktív kapcsolatot újra hozzá kell kapcsolni a megfelelő fiókhoz. Egy elutasított videónál javítani kell a fájlt vagy a beállításokat. Egy olyan feladatot pedig, amelynek médiafájlját eltávolították a tárolóból, nem lehet pusztán az újrapróbálkozás megnyomásával megjavítani.
Kérj újrapróbálkozást a bizonytalan kimenetelek megerősítése nélkül
Küldj egy POST /uploads/requests/REQUEST_ID/retry kérést a kiválasztott sikertelen feladatazonosítóval. Az alábbi JSON helyőrzőket használ az azonosítókhoz, és szándékosan false értéken hagyja a bizonytalan kimenetel megerősítését.
{
"taskIds": ["TASK_ID"],
"confirmUnknownOutcome": false
}Olvasd ki a válaszból mind a retried, mind a skipped mezőket. Egy sikeres HTTP-válasz is jelentheti azt, hogy egyetlen feladat sem indult újra. A 2026. október 17-i fejlesztői ellenőrzés során a bizonytalan kimenetelű tesztadat retried: 0 értéket és a kihagyott feladaton needsConfirmation: true jelzést adott vissza. Ez szándékos védelem: a rendszer nem hozza meg helyetted a publikálási döntést.
Ha a válasz olyan kihagyási okot (skip reason) tartalmaz, amely nem megerősítést igényel, először azt a feltételt javítsd ki. A teszt ellenőrizte az elutasítást inaktív célcsatorna, valamint a tárolóból eltávolítottként megjelölt videó esetén is. A megerősítő kapcsoló nem írja felül ezeket a blokkoló feltételeket.
Csak a platform ellenőrzése után erősítsd meg az újraküldést
Miután ellenőrizted a célplatformot, és az újrapróbálkozás mellett döntöttél, küldd el újra ugyanazt a kiválasztott feladatot confirmUnknownOutcome: true beállítással. Ez egy felelős publikálási döntés, nem pedig egy lejárt kapcsolat vagy hiányzó fájl javítása.
{
"taskIds": ["TASK_ID"],
"confirmUnknownOutcome": true
}A 2026. október 17-i szintetikus tesztünkben a megerősített feladat visszakerült queued (várólistás) állapotba, a próbálkozásszámlálója alaphelyzetbe állt, a kézi újrapróbálkozások száma pedig eggyel nőtt. A szülőkérés újra megnyílt, miközben a már korábban sikeresen befejezett testvérfeladat érintetlenül completed állapotban maradt. Ezek a megfigyelések az újrapróbálkozás kiválasztását és mentését igazolják, de nem garantálják a szolgáltató sikeres válaszát a következő kísérletnél.
Ellenőrizd az eredményt, és oldd fel a gyakori akadályokat
Kérd le újra a kérés részleteit. Egy várólistás (queued) vagy feldolgozás alatt álló (processing) feladatnak még nincs végső eredménye. Ellenőrizd a végső státuszt és a visszaadott cél-URL-t, majd erősítsd meg a poszt megjelenését a megfelelő fiókban. Kerüld az újabb publikálási kérések beküldését, amíg az újrapróbálkozás folyamatban van.
Jelenség | Vizsgálandó bizonyíték | Teendő |
|---|---|---|
Az újrapróbálkozás kihagy egy feladatot | Az | Ellenőrizd a célplatformot, mielőtt döntesz a megerősítésről. |
Az újrapróbálkozás szerint a kapcsolat inaktív | A pontos célfiók és annak kapcsolati állapota. | Csatlakoztasd újra az adott fiókot, majd értékeld újra a sikertelen feladatot. |
A médiafájlt eltávolították | Az újrapróbálkozás kihagyási oka és a médiatár elérhetősége. | Készíts elő elérhető médiát és új publikálási tervet; az újrapróbálkozás nem állítja helyre a törölt fájlt. |
HTTP 400-as hiba a | A fejlesztői tesztünk elutasította a tömb helyett küldött karakterláncot. | Küldj feladatazonosító karakterláncokból álló tömböt a fenti minta szerint. |
Ugyanaz a tartalom ismételten meghiúsul | Az új hibaüzenet és a platformspecifikus médiakövetelmények. | Ellenőrizd a forrást a videó-specifikáció ellenőrzővel, és javítsd a kiváltó okot a következő kísérlet előtt. |
A médiaformátum diagnosztizálásához használd a videó-specifikáció ellenőrzőt. Ha egy ismétlődő szabály folyamatosan újabb kísérleteket generál, a vizsgálat idejére tekintsd át és szüneteltesd a jövőbeli kiválasztásokat az ismétlődő ütemezések beállítási útmutatója alapján. A szabály szüneteltetése és egy már létrejött kérés rendezése két külön művelet.
Források és módszertan
Ellenőrizve: 2026. október 17. Az Uplonic működését az uploads útvonalban, a publikálási kérések újrapróbálkozási implementációjában és az újrapróbálkozási szabályzatban ellenőriztük, majd HTTP-n keresztül kipróbáltuk a media_api_dev ellen szintetikus hibákkal egy dedikált munkaterületen. A háttérfolyamat (worker) ébresztését a tesztben lecseréltük a tényleges kézbesítés megakadályozására. Vezérlőpult-kattintásokat, OAuth-újracsatlakozást vagy éles publikálást nem teszteltünk. A demórekordokat eltávolítottuk.
- RFC 9110: idempotens metódusok és újrapróbálkozási szemantika — ellenőrizve: 2026. október 17.; elméleti háttér a bizonytalan válasz és a bizonyítottan végre nem hajtott művelet megkülönböztetéséhez.
