mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-18 13:14:56 +03:00
cloudEnabled defaults to true in settings.ts::getSettings() for any install with no persisted settings row (every fresh install), so the create-key handler's unconditional `await syncKeysToCloudIfEnabled()` always attempted a real outbound fetch() to CLOUD_URL via syncToCloud(). When that endpoint is unset/unreachable/slow, the HTTP response blocked until the request settled or timed out (20-90s+), unlike sibling routes (regenerate, /api/combos) that never touch this side effect. syncKeysToCloudIfEnabled() is now dispatched fire-and-forget instead of awaited; its internal try/catch already logs failures, so cloud sync still runs in the background without blocking the response.
This commit is contained in:
committed by
GitHub
parent
48e902c9d0
commit
ede77d1df0
@@ -93,8 +93,15 @@ export async function POST(request) {
|
||||
});
|
||||
}
|
||||
|
||||
// Auto sync to Cloud if enabled
|
||||
await syncKeysToCloudIfEnabled();
|
||||
// Auto sync to Cloud if enabled — fire-and-forget. Cloud sync is a
|
||||
// background side-effect, not part of the key-creation contract, and it
|
||||
// performs an outbound network call. Awaiting it here blocked the HTTP
|
||||
// response on a slow/unreachable Cloud endpoint (e.g. a fresh/offline
|
||||
// install with a misconfigured or unreachable CLOUD_URL): the request
|
||||
// would hang until the fetch settled or timed out (#6570). Errors inside
|
||||
// syncKeysToCloudIfEnabled() are already caught and logged internally, so
|
||||
// this is safe to leave unawaited.
|
||||
void syncKeysToCloudIfEnabled();
|
||||
|
||||
return NextResponse.json(
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user