Deploy zamanı tipik xətalar və onların sazlanması üçün strategiya

1. Deploy anatomiyası: nə harada poza bilər

Əvvəlcə zənciri tam görmək faydalıdır. Sizin memarlıqda ChatGPT App‑in deployunu təxmini belə bir xətt kimi təsəvvür etmək olar:

flowchart TD
  A[Noutbukunuz
git commit] --> B[Git repozitoriyası
GitHub/GitLab]
  B --> C[Vercel Build
npm run build]
  C --> D[Vercel Deploy
Preview/Prod]
  D --> E[HTTP endpoint
/mcp, /api/...]
  E --> F[ChatGPT / Dev Mode
tool calls, widgets]

Səhv bu addımların istənilən birində yarana bilər, amma ChatGPT‑də simptomlar adətən eynidir: "Error talking to app", "Network error" və ya sadəcə sükut. Vəzifəniz — təsadüfi “atəş açmaq” deyil, əvvəlcə anlamaqdır: bu, build mərhələsində yıxılıb, icra zamanı baş verib, yoxsa ChatGPT ümumiyyətlə başqa yerə baxır.

Problemləri üç böyük kateqoriyaya bölmək rahatdır:

• Build xətaları: Vercel ümumiyyətlə layihəni yığa bilmir. Production yenilənmir — bu “yaxşıdır”, amma siz qırmızı build görürsünüz.
• Runtime xətaları: build keçib, amma sorğulara 500/502, taymautlar və ya qəribə davranış gəlir.
• Config drift (konfiqurasiya sürüşməsi): lokalda hər şey qaydasındadır, Vercel loglarında da problem görünmür, amma ChatGPT köhnə URL‑ə gedir, köhnə manifestlə işləyir və ya boş env dəyişənləri ilə qalır.

Bu üç qat üzrə irəliləyəcəyik və paralel olaraq ümumi sazlama (debug) strategiyasını inkişaf etdirəcəyik.

2. Build xətaları: layihə yığılmadıqda

Bu, girişdəki ilk tipdir — build xətaları: layihə ümumiyyətlə yığılmır, çünki Vercel sizin Next.js layihənizi uğurla yığa bilmir.

Node və Next.js: fərqli mühit, fərqli tələblər

Lokalda siz (təəssüf ki) köhnə Node ilə yaşaya bilərsiniz, Vercel isə sizin Next.js 16 layihənizi dəstəklənən Node versiyası ilə (minimum 18.18.0) yığmağa çalışacaq. Əgər package.json daxilində uyğunsuz versiya açıq şəkildə göstərilibsə, yığım prod‑da uça bilər, baxmayaraq ki, sizdə dev server işləyirdi.

Özünüzü qorumağın sadə yolu — package.json daxilində "engines"‑i açıq göstərməkdir:

{
  "engines": {
    "node": ">=18.18.0"
  }
}

Beləliklə, həm lokalda, həm də CI/Vercel‑də Node‑un çox köhnə olduğunu əvvəlcədən görəcəksiniz.

“Məndə işləyir!” və unudulmuş asılılıqlar

Klassika: siz npm install some-lib ilə kitabxana qurdunuz, amma yenilənmiş package-lock.json faylını commit etmədiniz və ya ümumiyyətlə asılılıqların bir hissəsi sizdə qlobal quraşdırılıb. Vercel‑də tətbiq “sıfırdan” yığılır, manifest əsaslı npm install dürüst icra olunur, amma sevimli some-lib orada yoxdur — nəticədə build error.

Burada sərt intizam kömək edir:

• bütün yeni asılılıqlar əlavə olunur və dərhal commit edilir;
• main/production‑a push etməzdən əvvəl lokalda npm run build işlədirsiniz. Lokal build yıxılırsa, Vercel‑də daha da pis olacaq.

Hərf böyüklüyünə həssas fayl sistemi (case‑sensitive)

Lokalda çoxları macOS və ya Windows istifadə edir, orada fayl sistemi susmaya görə fayl adlarında registri ayırd etmir. Vercel‑də yığım Linux mühitində gedir; orada Widget.tsx və widget.tsx — fərqli fayllardır.

Tipik bug:

// Koddakı import
import { AppWidget } from "@/components/Widget";

// Amma repozitoriyada components/widget.tsx faylı var

Kompüterinizdə hər şey işləyir, Vercel‑də isə modul xətası “Cannot find module '@/components/Widget'”. Həlli — adlarda nizam yaratmaq və registrə diqqətli yanaşmaqdır.

Build mərhələsində env dəyişənləri

Daha bir sürpriz mənbəyi — build mərhələsində icra olunan koddakı process.env.* istifadələridir (məsələn, next.config.mjs və ya build zamanı import olunan modullarda). Əgər lokalda .env.local faylını qoşmusunuzsa, amma Vercel‑də build mühiti üçün bu dəyişənləri yaratmağı unutmusunuzsa, yığım ya yıxılacaq, ya da — daha pis — undefined ilə keçəcək və etibarsız dəyərləri bundle‑a “bişirib” salacaq.

ChatGPT App üçün bu xüsusilə kritikdir; məsələn, MCP endpoint üçün baseURL‑i və ya xarici API‑lərin URL‑lərini elə build mərhələsində formalaşdırırsınızsa.

Yaxşı praktika — kritik env dəyişənlərini tətbiq startından əvvəl açıq şəkildə validasiya etməkdir (bunu ayrıca bölmədə danışacağıq), ki, build gur və proqnozlaşdırılan şəkildə yıxılsın.

3. Runtime xətaları: hər şey yığılıb, amma işləmir

İndi girişdəki ikinci qat — runtime xətalarına keçiririk: build keçib, amma icra zamanı hər şey qırılır.

Build keçib, Vercel yaşıl deploy göstərib, siz ChatGPT App‑i prod URL‑ə keçirmisiniz — və söhbətdə "Error talking to app" almısınız. Deməli, problemlər icra səviyyəsinə keçib.

Boş və ya təyin olunmamış env dəyişənləri

ChatGPT App dünyasında prod insidentlərinin çoxu undefined sözü ilə başlayır. Lokalda sizdə səliqəli .env.local var — OPENAI_API_KEY, MCP_BASE_URL və başqaları ilə, amma Vercel‑də bu dəyişənləri yaratmağı unutmusanız və ya adlarını qarışdırmısınız.

Məsələn, siz oxuyursunuz:

const apiKey = process.env.OPENAI_API_KEY;

amma Vercel‑də OPENAI_APIKEY və ya OPENAI_API_KEY_PROD yaratmısınız. Nəticədə, ilk MCP alət çağırışında sizin route handler autentifikasiya xətası ilə yıxılır.

Daha xoşu odur ki, tətbiq dərhal və anlaşılan şəkildə yıxılsın. Yaxşı pattern — Next.js layihənizdə import zamanı env dəyişənlərini validasiya edən ayrıca modul:

// app/lib/env.ts
const required = ["OPENAI_API_KEY", "MCP_BASE_URL"] as const;

type RequiredKey = (typeof required)[number];

function getEnv(key: RequiredKey): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Missing required env var: ${key}`);
  }
  return value;
}

export const env = {
  OPENAI_API_KEY: getEnv("OPENAI_API_KEY"),
  MCP_BASE_URL: getEnv("MCP_BASE_URL"),
};

İndi, əgər Vercel‑də dəyişənləri qurmağı unutmusunuzsa, Next.js ilk env importunda yıxılacaq və loglarda sivil bir mesaj görünəcək: "Missing required env var: ...".

Unutmayın ki, Vercel‑də env dəyişənlərinə edilmiş dəyişikliklər avtomatik tətbiq olunmur. Dəyərləri dəyişdikdən sonra yeni deploy (redeploy) etməlisiniz, yoxsa runtime köhnə dəyərlərlə yaşamğa davam edəcək.

Route handler‑lərdə və MCP endpoint‑də xətalar

Rəsmi ChatGPT App şablonunda MCP server adətən app/mcp/route.ts kimi reallaşdırılır. İçəridə JSON‑RPC sorğunu parse edən, onu alətə yönləndirən və cavab qaytaran kodunuz var. Zəncirdə haradasa emal olunmayan throw baş verərsə — ChatGPT istifadəçisinə 500 gələr.

Həmişə MCP handler‑in yuxarı səviyyəsini try/catch ilə bürümək, xətanı loglamaq və strukturlu cavab qaytarmaq lazımdır:

// app/mcp/route.ts
import { NextRequest, NextResponse } from "next/server";

export const dynamic = "force-dynamic";
export const maxDuration = 30; // saniyə

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    // burada MCP sorğusunun emalı
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json(
      { error: "Internal MCP error" },
      { status: 500 }
    );
  }
}

Bəzi məqamlar:

• dynamic = "force-dynamic" Next.js 16‑da MCP marşrutları üçün gözlənilməz statik generasiya və keşləmədən qaçmağa kömək edir.
• maxDuration = 30 Vercel‑ə route handler‑in 30 saniyəyədək işləyə biləcəyini açıq bildirir ki, bu da uzun LLM sorğuları üçün vacibdir.

Taymautlar və ChatGPT‑də “Network error”

Vercel serverless funksiyaların icra vaxtını məhdudlaşdırır: pulsuz tariflərdə bu adətən təxminən 10 saniyədir, ödənişli planlarda daha çox ola bilər (bir neçə dəqiqəyədək). Əgər sizin MCP alətiniz verilənlər bazasına və ya xarici API‑yə uzun sorğu edirsə, cavabı vaxtında verə bilməyə bilər və ChatGPT "Network error" və ya kəsilmiş stream görəcək.

Əgər qismən nəticələr üçün stream (SSE) istifadə edirsinizsə, xüsusilə vacibdir ki, taymaut bitməzdən əvvəl cavabın ilk baytlarını göndərəsiniz. Belə olduqda ötürmə özü daha uzun davam edə bilər, amma platforma funksiyanı “asılı qalmış” hesab etməyəcək.

Kiçik fənd: alət çağırışlarının vaxtını ölçün və onu alətin adı ilə birlikdə loglayın. Beləliklə, loglarda məsələn, search_flights çağırışının stabil olaraq 12 saniyə çəkməsini və limitə bir az sığmamasını görəcəksiniz.

export async function safeToolCall<TInput, TOutput>(
  name: string,
  handler: (input: TInput) => Promise<TOutput>,
  input: TInput
): Promise<TOutput> {
  const started = Date.now();
  try {
    const result = await handler(input);
    console.log("[tool] ok", name, { ms: Date.now() - started });
    return result;
  } catch (error) {
    console.error("[tool] fail", name, {
      ms: Date.now() - started,
      error,
    });
    throw error;
  }
}

Sonra handler(args) əvəzinə safeToolCall("search_flights", handler, args) çağırırsınız.

Şəbəkə və xarici xidmətlər

Bəzən məsələ sadəcə https:// əvəzinə http:// və ya köhnə baseURL‑dir. Xüsusilə əvvəlcə lokalda bir URL ilə test etmisinizsə, prod‑da isə artıq başqa domen və ya port varsa.

Baza URL‑ləri konfiqurasiyaya (mühitdən asılı) çıxarmaq və onları alətin kodunda bərk kodlamamaq faydalıdır. Belə olanda mühit dəyişəndə bir env dəyərini dəyişirsiniz, kodun beş yerində http://localhost:3001 axtarmırsınız.

4. Konfiqurasiya və mühitlərin drift‑i

Və nəhayət, sxemimizdə üçüncü tip — mühitlər arasında konfiqurasiya drift‑i.

Build keçsə və runtime loglara görə sağlam olsa belə, ChatGPT “sanki tətbiqin başqa versiyası işləyir” kimi davranış göstərə bilər. Bu, problem kodda yox, daha çox konfiqurasiyada və mühitlərin uzlaşdırılmasındadır.

Dev Mode vs production

Dev Mode‑da ChatGPT sizin əl ilə göstərdiyiniz Connector URL‑ə baxır: adətən bu, tunel URL‑idir (https://myapp-dev.ngrok-free.app/mcp və ya oxşarı) və ya Vercel‑də staging URL. Production‑da (Store vasitəsilə və ya təşkilat ayarlarında) App stabil prod endpoint‑ə işarə etməlidir, məsələn, https://myapp.vercel.app/mcp.

Demək olar ki, hamının etdiyi səhv: siz Vercel‑ə deploy etmisiniz, amma ChatGPT App ayarlarında hələ də köhnə tunel URL‑i göstərilib. Lokal server söndürülüb, tunel çoxdan ölüb, amma ChatGPT ora döyür və 502 alır. İnterfeys bunu "Error talking to app" kimi göstərir və tələbə MCP kodunu “təmir etməyə” başlayır — halbuki o ümumiyyətlə icra olunmur.

Həlli — intizam: hər mühit dəyişikliyindən sonra (tunel → staging, staging → prod) siz yoxlayırsınız, Dev Mode və prod App konfiqurasiyasında dəqiq hansı URL yazılıb.

Köhnə manifest və ChatGPT keşi

ChatGPT sizin App haqqında məlumatı keşləyəcək: alətlərin siyahısı, onların təsviri, meta məlumatlar. Buna görə “alətin sxemini dəyişdim, amma model hələ də arqumentin adının köhnə olduğunu düşünür” kimi hallar realdır.

Ciddi alət dəyişikliklərində faydalıdır:

• həqiqətən yeni versiyanı deploy etdiyinizi yoxlamaq (loglarda commit hash‑ə baxmaq, onu startup logunda çıxarmaq);
• App‑i Dev Mode‑da yenidən yaratmaq və ya yenidən qoşmaq ki, platforma manifesti yenidən oxusun;
• debug zamanı MCP Inspector vasitəsilə işləmək — orada alətlərin və sxemlərin aktual siyahısını dəqiq görürsünüz.

Env konfiqi: dev/staging/prod

Env dəyişənlərinin build və runtime‑ı necə yıxa biləcəyindən artıq danışmışdıq. Burada — dev/staging/prod və onların dəyərlərinin uzlaşdırılmasına yuxarıdan baxış.

Tez‑tez rast gəlinən ağrı: sizdə .env.local ideal, Vercel mühitlərində isə zoopark. Nəticədə:

• lokalda bir API açarı və xarici xidmət üçün bir URL;
• staging‑də tam başqa dəyərlər;
• prod‑da dəyişənlərin yarısı təyin olunmayıb.

Repozitoriyada sadə bir mətn faylı docs/env.md çox kömək edir — burada sadalayın: hansı dəyişənlər lazımdır, hansı mühitlərdə məcburidir, nümunə dəyərlər nədir. Bürokratiya kimi görünə bilər, amma insident zamanı belə siyahı saatlar qazandırır.

5. ChatGPT tərəfində xətalar necə görünür

İndi vəziyyətə ChatGPT istifadəçisinin gözü ilə baxaq. O yalnız interfeysi görür və Vercel, Node, MCP haqqında heç nə bilmir. Siz də, təəssüf ki, hələ nə pozulduğunu bilmirsiniz.

ChatGPT‑də tipik simptomlar:

• "Error talking to [App Name]" mesajı aləti istifadə etməyə cəhd edən kimi;
• sonsuz spinner, görünən xəta olmadan;
• qırmızı mətn "I encountered an error while running the tool";
• widget görünmür və ya boş görünür.

Bu simptomların hər biri adətən müəyyən “pozulma səviyyəsinə” uyğundur:

• əgər App ümumiyyətlə əlçatan deyilsə (yanlış URL, tunel yıxılıb, SSL xəta), ChatGPT sizin MCP endpoint‑inizə çata bilmir — brauzerdə domenin əlçatanlığını və Vercel loglarında 4xx/5xx kodlarını yoxlayın;
• əgər MCP error sahəsi olan etibarlı JSON‑RPC cavabı verirsə, ChatGPT dürüst şəkildə alətin xəta qaytardığını yazacaq — bu artıq biznes məntiqinə və ya arqumentlərin validasiyasına aiddir;
• əgər MCP uğurla cavab verir, amma cavabda widget‑ın HTML‑i qırıqdır və ya JS xətası var, onda widget konsolunda (DevTools → widget iframe‑i) nəyin yıxıldığını görəcəksiniz.

Ona görə yaxşı vərdiş: söhbətdə qəribə davranış görən kimi dərhal timestamp götürün (dəqiqəyə qədər) və həmin vaxta aid sorğuları Vercel loglarında axtarın.

6. Diaqnostika strategiyası: panik etmədən necə hərəkət etməli

İndi deyilənlərin hamısından kiçik bir “playbook” yığaq — nəsə səhv gedəndə hərəkətlər ssenarisi. Məqsəd — boşuna qaçış yerinə sakit alqoritm.

Addım 1: problemin tipini müəyyənləşdirin

Əgər Vercel‑də build qırmızıdırsa — sevinin: xəta production‑dan əvvəl tutulub. Build loglarını açın, ilk real xətaya baxın ( 200 sətrlik warninglərə yox) və lokalda npm run build komandasını işlədərək təkrarlayın.

Build yaşıl, amma ChatGPT şikayət edirsə — məsələ runtime və ya konfiqurasiya ilə bağlıdır. Yoxlayın:

• App‑inizin prod URL‑i brauzerdən əlçatandırmı (https://myapp.vercel.app/mcp heç nə qaytarırmı);
• MCP endpoint 200/500 qaytarır, yoxsa ümumiyyətlə resolve olunmur;
• App ayarlarında yazılan URL sizin indi yoxladığınızla üst‑üstə düşürmü.

Addım 2: fikirləri yox, logları oxuyun

Növbəti dayanacaq — Vercel logları: lazım olan deploy və mühit (Preview/Production) üçün server logları.

Axtarın:

• Error: Missing required env var ... xətalarını — deməli, problem konfiqurasiyadadır;
• MCP handler‑dən gələn stack trace — deməli, biznes məntiqi və ya giriş məlumatlarının parse edilməsi yıxılır;
• taymaut və ya funksiyanın müddətini aşma mesajları.

Paralel olaraq MCP Inspector‑u unutmayın. Eyni MCP endpoint‑ə inspector vasitəsilə qoşulub alətləri əl ilə çağırmaqla problemin MCP‑nin özündə, yoxsa ChatGPT ↔ MCP cütlüyündə olduğunu tez anlayacaqsınız.

Addım 3: sürətli rollback, yoxsa hotfix?

Əgər görürsünüzsə ki, prod deploy açıq‑aydın qırılıb (məsələn, MCP marşrutu hər sorğuda eyni xətanı atır), amma əvvəlki deploy sağlam idi — düzgün qərar geri qayıtmaqdır. Vercel əvvəlki uğurlu deploya yenidən yığmadan sürətlə keçməyə imkan verir — bu, mahiyyətcə aktiv versiyanın dəyişdirilməsidir.

Bu, production‑u “uçuşda” düzəltməyə cəhddən daha yaxşıdır, xüsusilə insidentin səbəbini tam anlamadığınız halda.

Vəziyyəti sabitləşdirdikdən sonra səbəbi sakitcə araşdırırsınız, testlər yazırsınız, kodda düzəliş edirsiniz və ancaq bundan sonra yeni versiyanı yayımlayırsınız.

Addım 4: bilikləri sənədləşdirməklə möhkəmləndirin

Hər ciddi insident — daxili README‑ni yeniləmək üçün səbəbdir:

• olmadan hər şeyin yıxıldığı məcburi env dəyişənini siyahıya əlavə edin;
• xətaya nəyin səbəb olduğunu qeyd edin (məsələn, “fayl adlarında yanlış registr ilə import”);
• tez bərpa etməyə kömək edən qısa hərəkət alqoritmini təsvir edin.

Bu darıxdırıcı görünə bilər, amma bir neçə aydan sonra özünüz özünüzə “sağ ol” deyəcəksiniz.

7. Kodda kiçik praktik üsullar

İndi playbook‑umuzdan bir neçə addımı götürüb tədris tətbiqimizdə (ChatGPT App) kiçik kod üsulları ilə möhkəmləndirək.

Birləşik konfiqurasiya modulu

Artıq sadə env dəyişənləri validasiyaedicisi yazmışdıq. Onu mühitləri ayırd edəcək şəkildə genişləndirmək olar:

// app/lib/config.ts
type NodeEnv = "development" | "test" | "production";

const nodeEnv = (process.env.NODE_ENV || "development") as NodeEnv;

const requiredBase = ["OPENAI_API_KEY"] as const;
const requiredProd = ["MCP_BASE_URL"] as const;

function ensure(keys: readonly string[]) {
  for (const key of keys) {
    if (!process.env[key]) {
      throw new Error(`Missing env var ${key} for NODE_ENV=${nodeEnv}`);
    }
  }
}

ensure(requiredBase);
if (nodeEnv === "production") {
  ensure(requiredProd);
}

export const config = {
  nodeEnv,
  openaiApiKey: process.env.OPENAI_API_KEY!,
  mcpBaseUrl: process.env.MCP_BASE_URL ?? "http://localhost:3000/mcp",
};

Belə modul prod mühitinin lazım olan dəyişən olmadan işə düşdüyünü dərhal üzə çıxaracaq.

Gələn MCP sorğularının loglanması

Sadə, amma çox faydalı bir obvyozka MCP handler üçün:

// app/lib/mcp-logger.ts
export function logMcpRequest(body: unknown) {
  console.log("[mcp] request", {
    time: new Date().toISOString(),
    // həssas məlumatları loglamırıq
    keys: typeof body === "object" && body !== null
      ? Object.keys(body as Record<string, unknown>)
      : typeof body,
  });
}

Və bunu app/mcp/route.ts daxilində istifadə edirik:

import { logMcpRequest } from "@/app/lib/mcp-logger";

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    logMcpRequest(body);
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json({ error: "Internal error" }, { status: 500 });
  }
}

Loglarda ChatGPT‑dən ümumiyyətlə nə gəldiyini görəcəksiniz: heç olmasa açarları ("jsonrpc", "method", "params") üzrə və hansı çağırışın yıxıldığını daha asan anlayacaqsınız.

MCP endpoint‑in əlçatanlığının sadə yoxlanması

Bəzən MCP server üçün kiçik “healthcheck” tipli route handler‑ə sahib olmaq faydalıdır — ChatGPT bu marşrutu birbaşa çağırmır, amma siz onu brauzerdə tez aça və serverin canlı olub‑olmadığını, env dəyişənlərini görüb‑görmədiyini anlaya bilərsiniz:

// app/api/health/route.ts
import { NextResponse } from "next/server";
import { config } from "@/app/lib/config";

export async function GET() {
  return NextResponse.json({
    status: "ok",
    env: config.nodeEnv,
    hasOpenAiKey: !!config.openaiApiKey,
  });
}

Əgər https://myapp.vercel.app/api/health status: "ok" qaytarırsa, deməli ən azı pipeline‑ın Node kodunuza qədər olan hissəsi yaşayır.

8. Deploy və diaqnostika zamanı tipik səhvlər

Xəta №1: Lokal npm run build olmadan deploy.
Tərtibatçı heç vaxt lokala build işlətdirmirsə, uyğun olmayan Node versiyası, yol problemi və ya TS xətası barədə yalnız Vercel‑də öyrənir. Bu, “sındı → düzəltdi” dövrünü uzadır, çünki hər eksperiment yeni deploy deməkdir. Pushdan əvvəl npm run build işlətdirmək vərdişi çox vaxt qazandırır (bax həmçinin bölmə 2 və addım 6.1 — lokal npm run build haqqında).

Xəta №2: Sirlər yalnız .env.local daxilində qalıb.
Layihə müəllifin maşınında əla işləyir, amma prod‑da process.env.OPENAI_API_KEY === undefined üzündən yıxılır. Səbəb banal: env dəyişənlərini Vercel ayarlarında əlavə etməyi unutdular (bəzən adları da başqa cür yazılır). Xüsusilə Development/Preview/Production bölgüsünü unudurlar və təəccüblənirlər ki, staging və prod fərqli davranır (ətraflı — bölmə 3.1, 4.3 və 7.1).

Xəta №3: Sirlər üçün NEXT_PUBLIC_* istifadəsi.
Next.js‑də NEXT_PUBLIC_ prefiksi olan bütün dəyişənlər brauzer bundle‑ına düşür. Diqqətsizlikdən API açarına NEXT_PUBLIC_OPENAI_API_KEY adını versəniz, o, istifadəçinin brauzerinə gedəcək və devtools‑dan çıxarıla biləcək. Belə etmək olmaz. Publik olmalı olan yalnız təhlükəsiz dəyərlərdir (məsələn, feature flag identifikatorları, amma tokenlər yox).

Xəta №4: Vercel loglarını görməzdən gəlib “ChatGPT ilə düzəltməyə” cəhd etmək.
Bəzən tərtibatçı söhbətdə "Error talking to app" görüb saatlarla promptları, alət təsvirlərini dəyişir, Dev Mode‑da nələrisə qurdalayır, amma serverless loglara bir dəfə də baxmır. Halbuki orada çox anlaşılan xəta dayanır: "Missing env var", "Cannot find module" və ya konkret alətin stack trace‑i. Yaxşı mühəndis əvvəlcə loglara baxır, sonra model ilə “mübahisə edir”.

Xəta №5: Dev Mode və production App‑in qarışdırılması.
İlk uğurlu Vercel deployundan sonra asanlıqla yaddan çıxır ki, Dev Mode hələ də köhnə tunelə və ya preview URL‑ə baxa bilər. Nəticədə siz əminsiniz ki, production versiyanı test edirsiniz, amma əslində çoxdan silinməli olan lokal budaqla danışırsınız. Və ya əksinə: elə bilirsiniz ki, qaralama düzəlişləri test edirsiniz, amma ChatGPT döyüş endpoint‑inə gedir. App və Dev Mode ayarlarında hansı URL‑in yazıldığını mütəmadi yoxlamaq lazımdır (bax həmçinin bölmə 4.1 — Dev Mode və production haqqında).

Xəta №6: Vercel‑də env dəyişəninin dəyişməsinin “uçuşda” işləyəcəyini gözləmək.
Bəzi tələbələr Vercel panelində dəyişən dəyərlərini dəyişir və dərhal ChatGPT‑də nəticəni yoxlamağa qaçır. Amma runtime hələ də köhnə dəyərlərdən istifadə edir, çünki redeploy olmayıb. Env dəyişənində istənilən dəyişiklik yeni deploy tələb edir, yoxsa funksiya yenilənməni görməyəcək (ətraflı — bölmə 3.1).

Xəta №7: Sadə rollback strategiyasının olmaması.
İnsident anında “tez bir fix”i birbaşa main‑ə push etmək çox cazibədardır. Amma bu, daha bir potensial qırıq deploy əlavə edir və istifadəçilər bu müddətdə əziyyət çəkirlər. Daha sakit yanaşma — ciddi xəta zamanı dərhal əvvəlki uğurlu deploya qayıtmaq, problemi ayrıca budaqda düzəltmək və yalnız sonra yeni versiyanı buraxmaqdır. Vercel bunun üçün rahat interfeys verir, istifadə etməmək günahdır.