Đây là những câu hỏi kiểu “bạn làm việc thế nào?”. Junior kể tool rồi dán interceptor axios xóa storage và đá về login. Senior nói hàng đợi refresh, ticket thành thật, git trunk-based, incident mitigate trước, và bản đồ tuần 1 của một codebase Vue.

Đọc 18.1 trước (401 không phải logout). Rồi 18.2–18.3 cho cách cắt việc và triage. 18.4–18.6 là cơ chế git. 18.7 là thời điểm xử lý incident. 18.8 là tuần 1. Vue 3 / Nuxt trước; cơ chế 401 áp cho React/Next. Khác leadership 17.x: artefact ở đây là playbook, không phải giọng mentoring.

Tóm tắt: 401 nghĩa là “access token fail”, chưa phải “logout user”, cho đến khi refresh cũng fail. Bỏ qua route auth, single-flight một lần refresh, replay một lần, rồi mới logout mọi tab với URL trả về an toàn. 403 là chuyện quyền: đừng logout. Khác Q&A JWT login-flow và hàng đợi refresh: ở đây UI redirect và hàng đợi sống cùng nhau.

Vì sao quan trọng: “API trả 401, client làm gì?” Interceptor junior xóa storage rồi router.push("/login"). Họ chờ bạn nói refresh, hàng đợi, vòng lặp, URL trả về, đa tab, và 401 khác 403. Login POST 401 vì mật khẩu sai: đó không phải hết session.

1. Cách hoạt động: Bỏ qua /login, /logout, /refresh. Một promise refresh in-flight; mọi request khác chờ. Thành công → retry request gốc một lần. Fail → xóa query cache, BroadcastChannel logout, đi tới login với redirect chỉ là path nội bộ tương đối (safeInternalPath).
2. Giữ URL trả về để form dài không mất, nhưng open-redirect là lỗ hổng: chỉ nhận path bắt đầu bằng / và không phải //. Redirect hay hiện modal “hết session” trên form dài (lưu draft trước) là product quyết.
3. SSR: đừng để document bị redirect loop. 401 lúc server render /app thì render location login một lần. Đừng gọi useRoute() ngoài setup: hãy truyền currentRoute. Tám useAsyncData chạy song song không được thành tám redirect.

let refresh: Promise<boolean> | null = null
const authChannel = new BroadcastChannel("auth")
function safeInternalPath(p: string) {
  return p.startsWith("/") && !p.startsWith("//") ? p : "/app"
}
export async function on401(ctx: { url: string; path: string; retry: () => Promise<unknown> }) {
  if (/\/api\/auth\/(login|logout|refresh)/.test(ctx.url)) throw new Error("auth-route-401")
  if (!refresh) {
    refresh = $fetch("/api/auth/refresh", { method: "POST" }).then(() => true).catch(() => false)
      .finally(() => { refresh = null })
  }
  if (await refresh) return ctx.retry()
  queryClient.clear()
  authChannel.postMessage({ type: "logout" })
  await navigateTo({ path: "/login", query: { redirect: safeInternalPath(ctx.path) } })
}

Điều gì xảy ra: Tám 401 chia một refresh. Mật khẩu sai trên /login thì throw, không xóa session. Sau khi refresh fail, mọi tab logout và login nhận /orders/42, không phải https://evil.test. 403 không bao giờ vào hàm này.

Lỗi hay gặp

• Logout mọi 401. Triệu chứng: một blip đá user. Nguyên nhân: không refresh. Cách xử lý: refresh single-flight.
• redirect=https://evil.test. Triệu chứng: open redirect. Nguyên nhân: lấy query thô. Cách xử lý: safeInternalPath.
• Coi 403 như 401. Triệu chứng: trang cấm lại logout. Cách xử lý: copy khác, ở lại session.
• Tám redirect từ tám useAsyncData. Triệu chứng: nháy. Nguyên nhân: không promise chung. Cách xử lý: singleton refresh.

Tóm tắt: Jira hay Linear không quan trọng. Việc của bạn là lát dọc, status thành thật, rủi ro sớm, và một increment user nhìn thấy được. Tool là database. Done nghĩa là empty/error/bàn phím, không phải “trông như Figma”.

Vì sao quan trọng: “Jira hay Linear?” Họ không quan tâm tool nào. Họ quan tâm bạn cắt việc thế nào, giữ status thành thật, và nêu rủi ro trước Friday. Việc FE hay giấu trong “90% xong, chờ API”. Nếu board không hiện điều đó, bạn đang nói dối.

1. Cách hoạt động: Một path user kèm loading/error/empty, không phải “hết component rồi hết API”. Definition of done cho control Vue: empty, error, không quyền, bàn phím, một test trên chỗ rủi ro.
2. Viết rủi ro VAT-API lên ticket lúc planning. Spike là spike, không phải feature. WIP mới là vấn đề thật; tool map chỉ là footnote. Team FE sản phẩm thường làm Kanban kèm lớp planning tuần; đừng chết vì trivia Scrum khác Kanban.

3. PM viết giải pháp chứ không phải vấn đề là 17.5 (nói không). Bug prod không kế hoạch khác sprint là 18.3 /

   • 1
   • 8.7. Status “in review” ba ngày mà không nêu reviewer là bug process bạn chịu trách nhiệm.

Lỗi hay gặp

• Lát ngang (hết API, rồi hết UI). Triệu chứng: không gì demo được. Cách xử lý: một path.
• Coi spike là feature. Triệu chứng: “90% xong” mãi. Cách xử lý: time-box, rồi quyết.
• Chiến tranh tool. Triệu chứng: trượt vòng. Nguyên nhân: họ hỏi về việc, không phải Jira.
• Done = khớp Figma. Triệu chứng: không empty, không bàn phím. Cách xử lý: DoD gồm những thứ đó.

Tóm tắt: So báo cáo với product contract. Nếu user kỳ vọng hợp lý và mình làm gãy, đó là defect. Mức nghiêm trọng (thanh toán, khóa auth, mất data, màn trắng) quyết hotfix hay sprint sau, không phải loại ticket Jira.

Vì sao quan trọng: “Đây là bug hay feature?” Họ test xem bạn cãi nhãn Jira hay nói contract, mức nghiêm trọng, và impact lên user. Support ghi mọi thứ là bug. Sales ghi mọi thứ là hotfix. Khác 18.2 (cách cắt việc) và 18.7 (khi production đang cháy).

1. Cách hoạt động: Contract nằm trong spec, ADR, copy UI, API docs, và legal. Nút Export hiện trên UI mà không làm gì là UI-contract defect. “Xin thêm export” là thay đổi. Fail WCAG trên control đã ship là defect, không phải nice-to-have.
2. Mức nghiêm trọng, không phải loại ticket, quyết thời điểm xử lý. Sev-1 (thanh toán, khóa auth, mất data, màn trắng trên /): mitigate ngay. Sev-2: trong ngày. Sev-3: xếp lịch. Cosmetic ở lại backlog. On-call kèm PM quyết mức; frontend mang blast radius từ RUM.
3. “Won’t fix” cần lý do ghi lại. Một “bug” thầm lặng mà thật ra là đổi rule giá thì thuộc product và legal. Đừng dán lại nhãn một miss để bảo vệ dashboard SLA. Revert nếu blast radius là cả release; fix forward nếu revert tệ hơn.

Lỗi hay gặp

• Cãi loại Jira trong khi checkout đang gãy. Triệu chứng: user phải chờ. Sửa: mức nghiêm trọng trước, nhãn sau.
• Coi requirement v1 còn thiếu là “feature” để tránh hotfix. Triệu chứng: SLA trông xanh. Sửa: ghi lại miss.
• Ship một “bugfix” thực ra là đổi schema, không có PM. Triệu chứng: product bất ngờ. Sửa: đó là thay đổi.
• Dùng “là feature” để bỏ RCA. Triệu chứng: lỗ hổng mở lại. Sửa: RCA trên escaped defect.

Tóm tắt: Team Vue product ship mỗi ngày thì chạy trunk-based: branch sống ngắn, PR, CI gate, flag cho việc chưa xong. GitFlow (develop, release/*, hotfix/*) chỉ khi bạn thật sự phải giữ vài version đang live.

Vì sao quan trọng: “GitFlow hay trunk-based?” Nhiều deck vẫn vẽ GitFlow. Team Vue product ship mỗi ngày thì thường không nên. Họ muốn main luôn releasable, không phải develop thối. Khác 14.2 (pipeline CI) và 18.6 (squash lúc merge).

1. Cách hoạt động: main luôn releasable. Muốn vậy phải có CI gate và flag. main được bảo vệ: review, CI xanh, không force-push. Conventional commit (feat:, fix:, perf:, revert:) cho changelog và grep, không thay cho mô tả PR.
2. Branch sống vài giờ đến vài ngày. Lát lớn hơn thì integrate sau flag. GitFlow khi bạn giữ mobile wrapper, on-prem, hoặc lịch release bị regulate. Đừng chạy vì blog nói “phổ biến nhất”. feature/user-profile dài cả tuần và develop thối là thất bại.
3. Hotfix: branch từ tag prod, hoặc revert rồi fix forward trên trunk nếu bạn deploy từ main. Dùng GitFlow, flag, và preview env là ba cách giấu việc chưa xong nếu không cái nào có owner. main xanh mà CDN đang serve HTML cũ là bug delivery, không phải bug git.

git checkout main && git pull
git checkout -b feat/csv-export-orders
# UI chưa xong đứng sau flag csv_export
git commit -m "feat: csv export for orders table"
git push -u origin feat/csv-export-orders
# PR: lint, vue-tsc, unit, preview, rồi squash vào main
# GitFlow (develop + release/*) chỉ khi vẫn ship v1.4 và v1.5
# hotfix: branch từ tag prod, không từ develop già một tuần

Điều gì xảy ra: Branch ngắn từ main, việc chưa xong đứng sau flag, squash-merge qua CI. GitFlow tắt trừ khi hai version cùng đang live. Dòng hotfix lấy từ tag prod để bạn không dính develop thối.

Lỗi hay gặp

• GitFlow vì blog nói “phổ biến nhất”. Triệu chứng: develop thối. Sửa: trunk, trừ khi có vài version.
• feature/user-profile dài cả tuần. Triệu chứng: không merge được. Sửa: flag và PR ngắn.
• Conventional commit cho có hình thức khi main không bisect được. Sửa: squash lúc merge (18.6).
• main xanh, HTML cũ trên CDN. Triệu chứng: “git ổn”. Sửa: đó là delivery, không phải git.

Tóm tắt: Rebase branch sống ngắn nếu bạn là người push duy nhất. Không bao giờ rewrite lịch sử dùng chung. Marker biến rồi, chạy feature: semantic conflict không hiện <<<<<<. Push với --force-with-lease.

Vì sao quan trọng: “Rebase hay merge, và conflict bạn không thể cứ chọn một phía”. Họ muốn semantic conflict, --force-with-lease, và chạy path sau khi marker biến. Git resolve text, không phải hành vi. Khác 18.4 (workflow nào) và 18.6 (squash).

1. Cách hoạt động: Rebase branch ngắn lên origin/main nếu chỉ bạn push. Merge main vào branch dùng chung. Sau conflict, chạy suite: hai PR có thể cùng thêm useUser, register /orders hai lần, hoặc ghi đè i18n key rồi vẫn merge sạch.
2. --force-with-lease từ chối đè những commit trên remote bạn chưa thấy. Không bao giờ rebase commit đã nằm trên main. Không bao giờ rebase feature branch public mười người đang dùng. Không bao giờ force-push branch đã rebase khi reviewer đã checkout mà chưa báo trước.
3. Conflict binary (ảnh, Figma): chọn một phía, đừng merge. Conflict lockfile: generate lại (pnpm install), đừng sửa tay pnpm-lock.yaml. Conflict khó thì hãy pair, đừng đoán mò bốn mươi phút.

git fetch origin
git rebase origin/main
# CONFLICT src/stores/user.ts: hai PR cùng thêm useUser
# Git resolve được text; không resolve hành vi
git add src/stores/user.ts
git rebase --continue
git push --force-with-lease origin HEAD
pnpm test && pnpm exec playwright test user-profile
# lockfile: pnpm install, commit lock đã generate lại, đừng merge tay

Điều gì xảy ra: Rebase phát lại commit của bạn lên main hiện tại. Hai helper useUser có thể merge sạch rồi crash lúc chạy. --force-with-lease chỉ cập nhật branch remote khi không ai khác đã push. Dòng cuối mới là test thật: click lại path.

Lỗi hay gặp

• git push --force sau rebase. Triệu chứng: bạn đè commit của đồng đội. Sửa: --force-with-lease.
• Dừng khi compiler xanh. Triệu chứng: hai useUser crash lúc chạy. Sửa: chạy lại path.
• Sửa tay pnpm-lock.yaml. Triệu chứng: dependency ảo. Sửa: generate lại.
• Rebase main hoặc branch dùng chung. Triệu chứng: lịch sử public bị rewrite. Sửa: không bao giờ.

Tóm tắt: Squash lúc PR merge để main bisect được: một commit cho mỗi thay đổi review được. Không bao giờ squash lịch sử public đã nằm trên main. Sửa bằng commit mới hoặc git revert. Đừng squash cả tuần việc không liên quan thành một cục.

Vì sao quan trọng: “Bạn có squash không?” Có phạm vi đúng: feature branch ồn khác lịch sử public đã trên main khác cả tuần việc không liên quan trong một commit. git bisect và git revert là tool production. Khác 18.4 (workflow) và 18.5 (conflict lúc rebase).

1. Cách hoạt động: GitHub “Squash and merge” cho branch wip và “fix typo”. Title PR thành commit trên main và gắn số PR. Giữ vài commit logic riêng chỉ khi mỗi cái đều xanh và team muốn revert từng phần. Commit fixup lúc review vẫn để private (--fixup, rồi rebase lúc cuối).
2. Khi đã lên main, lịch sử là audit log. GitOps thích kiểu này. Merge WIP 400 commit thì team khổ. Một squash cả tuần việc không liên quan cũng vậy. Rebase-merge chỉ khi author đã chọn lọc commit. Merge commit giữ topology và ồn hơn.
3. Không bao giờ interactive-rebase main. Không bao giờ squash mất một revert. Không bao giờ rewrite commit đã review rồi force-push mà không có --force-with-lease. Changelog từ conventional commit sẽ sai khi mọi squash đều là feat:. Tách refactor lẫn lộn ra khỏi squash.

git rebase -i origin/main
# pick feat, squash wip, squash "fix typo"
git commit --amend -m "feat: csv export for orders (#842)"
# KHÔNG BAO GIỜ rewrite main:
#   git rebase -i main          # sai: lịch sử public
# khi đã lên main, lịch sử là audit log:
git revert abc123 --no-edit   # bug checkout; DS token là PR khác
git log --oneline origin/main | head

Điều gì xảy ra: Các commit wip ồn gộp thành một SHA review được trên main. Dòng revert chỉ chạy được vì checkout và token design-system là PR khác nhau. Nếu chúng nằm chung một squash, bạn không revert được một cái mà không kéo theo cái kia.

Lỗi hay gặp

• Squash main. Triệu chứng: audit log bị rewrite, GitOps rối. Sửa: revert hoặc thêm commit.
• Một squash gồm checkout và token DS. Triệu chứng: không revert được một cái. Sửa: tách PR.
• Interactive rebase lịch sử public. Triệu chứng: đồng đội lạc chỗ trên history. Sửa: không bao giờ.
• Mọi squash mang title feat:. Triệu chứng: changelog nói dối. Sửa: khớp đúng loại thay đổi.

Tóm tắt: User không login được và bạn đang on-call. Mitigate trước, debug sau: rollback digest, tắt flag, hoặc purge HTML lỗi. Rồi comms, evidence, và một fix hệ thống. Khác Q&A debug production (JSON có đúng không) và khác 19.5 (có gọi pager hay không).

Vì sao quan trọng: “User không login được. Bạn đang on-call. Làm đi”. Họ muốn mitigate trước: rollback, flag, purge HTML. Không phải soi Vue minify suốt bốn mươi phút. Thường thì bạn không SSH được vào CDN. Khác 17.7 (giọng cập nhật status) và 19.6 (các bước gạt flag chi tiết).

1. Cách hoạt động: Xác nhận là thật: Sentry, RUM, và một lần repro. Check release, environment, flag, locale, browser. Rồi chọn đòn bẩy theo blast radius, không theo lý thuyết.
2. 100% sau deploy: rollback digest GitOps. Khoảng 10% và có tag flag: đưa flag về 0% (19.6). Một region: CDN. Chỉ login: auth (18.1), không phải chart. Chunk 404 hoặc màn trắng: purge HTML. Đừng restart pod SSR vì lỗi index.html bị cache.
3. Nói rõ đã biết gì, impact, lần cập nhật tiếp: có mốc giờ. Giữ event Sentry, SHA, và phần trăm flag trước khi rollback. Kiểm chứng bằng login canary và Sentry về baseline (để ý traffic). RCA để sau: map, timeline, một CI gate để lỗ này không mở lại. Đừng ship một fix đoán mò lên main lúc đang cháy.
4. API 500 kèm toast frontend thì comms vẫn là của bạn nếu bạn phụ trách UI. Đừng giữ rollback frontend nếu JS ổn. “Chạy được trên staging” với SHA khác không phải evidence. Thiếu source map nghĩa là bạn đang đoán (19.1).
5. Thực hành: một buổi game day làm sập service flag hoặc phá chunk hash. Thời gian mitigate và phần trăm user hồi (RUM) mới là điểm, không phải slide RCA đẹp thế nào.

Lỗi hay gặp

• Soi Vue minify khi user đang cháy. Triệu chứng: bốn mươi phút, vẫn down. Sửa: digest, flag, hoặc purge trước.
• Restart Nitro vì HTML trên CDN. Triệu chứng: pod flap, HTML vẫn vậy. Sửa: purge HTML.
• Ship fix đoán mò lên main lúc đang cháy. Triệu chứng: incident thứ hai. Sửa: mitigate, rồi mới PR đàng hoàng.
• Đổ lỗi backend khi không có HAR. Triệu chứng: bạn đoán. Sửa: playbook isolation trong Q&A debug.

Tóm tắt: Tuần 1 của một Nuxt monolith là bản đồ trong đầu và một contribution đúng kiểu production trước Friday. Chạy được, lần một path, tìm chỗ ghép, ship một ticket nhỏ kèm test. Không phải một tuần im lặng đọc code, cũng không phải rewrite folder.

Vì sao quan trọng: “Thứ Hai bạn vào một Nuxt monolith. Bạn làm gì?” Họ muốn một bản đồ và một ticket thật, không phải vẻ chắc chắn giả. Không ai có architecture doc còn đúng. Auto-import giấu dependency. Câu ước lượng Friday (17.3) muốn một list rủi ro.

1. Cách hoạt động: Ngày 1: clone, build prod-mode, test; ai on-call, Sentry ở đâu, deploy thế nào; lướt ADR về auth và rendering. Ngày 2: lần login và một core path trong DevTools (network, Vue, Pinia).
2. Ngày 3: map feature khác shared, tìm design system, chạy bundle analyzer một lần. Ngày 4–5: một ticket thật nhỏ trên path đó, kèm test. 1:1: hỏi chỗ chết người (hydration, module federation, e2e flaky). Pair deploy và auth; xen với lúc explore một mình.
3. Access staging chậm: dùng preview và Storybook, nhưng nhất quyết phải có RUM prod trước tuần 2. Đừng giả định pattern Nuxt 3 trong app Nuxt 2 kèm Vuex. Dev trên mock giấu BFF là bẫy. Output tuần 1 là list rủi ro, không phải rewrite architecture.

Lỗi hay gặp

• Im một tuần “đọc”. Triệu chứng: Friday bạn không vẽ được hộp. Sửa: lần một path ngày 2.
• Rewrite folder structure. Triệu chứng: bạn tốn vốn chính trị. Sửa: một ticket nhỏ.
• Lint 200 file tiện tay, hoặc refactor Pinia vì nhớ Vuex. Triệu chứng: nhiễu. Sửa: từ chối.
• Bỏ env giống prod (flag, SSR). Triệu chứng: ticket ngày 5 nói dối. Sửa: nhất quyết phải có flag và build prod.