Onboard 6 nhà, một đơn đặt trùng, và bản thiết kế để nó không lặp lại

Tổng quan tuần

Tuần này có ba việc lớn. Một: onboard đợt 17/09 — 6 nhà, 21 phòng, 219 ảnh lên production ở trạng thái ẩn, kèm hai lỗi importer làm rơi dữ liệu trong im lặng. Hai: một đơn đặt trùng thật (CS-A9DG) và miếng vá đệm dọn hai đầu — vá xong thì vận hành báo ngược lại rằng miếng vá đang ăn mất khung bán. Ba: thiết kế lại phần sync phòng để đưa hẳn vào ChicStay backend, mới là thiết kế, chưa apply code.

Phần việc của mình ở repo chicstay-backend tuần này chỉ là sync phòng. 29 commit tính năng của repo đó (engine bán thêm giờ, quy trình xác nhận booking, Control Tower) là của đội dev ChicStay; mình ở phía review và gộp 4 PR — ghi ở mục D.

A. Onboard đợt 17/09 — 6 nhà, 21 phòng chicdata → ChicStay, tất cả ẩn

A1. Hai lỗi importer làm rơi dữ liệu mà không báo gì

Dry-run in ra “8 cơ sở · 0 phòng” trong khi sheet có 78 dòng phòng đã tick. Bộ nhập đọc mã cơ sở ở cột Mã cơ sở của tab 02_Phòng, nhưng tiêu đề cột đó đang bị gõ đè thành zZZ. Mọi dòng ra undefined rồi rơi vào một lệnh continue câm — gói giá, album và tiện ích đều treo vào phòng nên biến mất theo.

Nay mã cơ sở được suy theo tên cột đã cắt khoảng trắng, rồi theo tiền tố CS#### của Mã phòng, và bỏ dòng nào thì ghi vào skipped thay vì im lặng. Lỗi thứ hai: ô “Chỉ Thứ 2 - Thứ 8” của Kat House vi phạm CHECK constraint và rollback cả lượt nạp 8 cơ sở — giá trị ngoài từ vựng nay về “Khác (ghi rõ ở Ghi chú)” kèm cảnh báo. Không đoán đó là Thứ 5 hay Thứ 6, vì đoán sai là bán sai giá.

A2. Nạp vào chicdata — chỉ thêm, không sửa, không xoá

Cơ sở và phòng để DRAFT, merchant để portal_enabled=false. Kiểm cả 4 bảng: số dòng cũ bị sửa bằng 0. Sao lưu trước khi nạp bằng Neon branch backup-prod-before-onboard-20260917.

A3. Ảnh — 219 ảnh cho 18 phòng, kiểm tới từng tấm

Chạy lại push_room_albums_to_r2.py đúng chuẩn nén cũ (WebP q80, cạnh dài ≤1600px): 500 MB ảnh gốc còn 19,5 MB, bảng media 6.239 → 6.458, không dòng cũ nào bị sửa. Ảnh mỗi phòng: Demo 10–19, Chạm 2–9, Kat House 9–13, Biko 18–30.

Không chỉ tin script chạy xanh: quét trước 18 album (không thư mục con, video, HEIC, file >20MB); tải lại cả 219 ảnh từ R2 đối chiếu checksum/dung lượng/kích thước với DB; so nội dung từng ảnh R2 với ảnh gốc trên Drive — lệch tối đa 5/256, tức mọi ảnh đều gắn đúng phòng; mỗi phòng đúng 1 ảnh bìa.

Trong lúc kiểm tìm ra một lỗi thật: ảnh chụp dọc lên R2 thành nằm ngang — WebP không mang EXIF theo nên 2 ảnh của Chạm Dịch Vọng Hậu ra 1600×720 thay vì 720×1600. Đã vá script, 4 test tái hiện, đẩy lại 2 ảnh. Ghi thêm một chuyện tự gây ra: lúc quét album tôi tải hàng loạt ảnh gốc nên bị Google trả 403 tạm; đã dừng và chuyển sang đọc metadata Drive. Key này dùng chung với phần sync Google Sheet.

A4. Nạp lên ChicStay production

• Export 8 merchant ra exports/chicstay-onboarding-2026-09-17.json → ra 6 cơ sở · 21 phòng · 69 gói · 219 ảnh. AN25 Hoàng Mai và Ora Hotel không có mặt vì sheet 0 dòng phòng.
• Bỏ 48 trường internal_note* trước khi đưa lên, nên mã cửa không lên ChicStay.
• Sao lưu backup-prod-before-chicstay-import-20260917; lệnh nạp chỉ chạy tiếp nếu dry-run trên dữ liệu prod ra 0 cập nhật, 0 xoá — và kết quả đúng như vậy.
• Kiểm lại sau khi nạp: 21 phòng đều hidden + is_active=False; cả 21 đã có chicdata_room_id nên nhà nào có nguồn lịch là lịch tự chảy về, không phải sửa gì thêm.
• Hai phòng ít hơn chicdata 1 ảnh (Kat House tầng 3, Biko “Studio có sân hiên”) vì file ảnh trùng nhau nên ChicStay giữ một bản — không phải mất ảnh.

A5. Không nhà mới nào tự đồng bộ lịch được

Trả lời câu hỏi của Thu Phương: cả 8 nhà đợt này không nhà nào nối lịch tự động được — Chạm dùng AppSheet, Ora là link booking.com, Biko là link agoda (thiếu https:// nên còn không dựng nổi availability_config), Blue Diamond / Kat House / AN25 đều “đóng mở trực tiếp”. Riêng DEMO Inn&Ine có sổ Google nên đã nối được (mục C2). Blue Diamond vẫn 3 phòng 0 ảnh, BD sẽ bổ sung.

A6. Tích luỹ: sheet onboarding đã đẩy được bao nhiêu lên ChicStay

Đếm trên chính chicdata theo dấu nguồn chicstay-data-sheet — tức toàn bộ những gì sheet onboarding đã sinh ra từ trước tới nay: 31 merchant · 84 cơ sở · 423 phòng · 1.893 gói giá. Trong đó 305 phòng đã nối được PMS (mục E); phần còn lại là nhà không có nguồn lịch tự động, đúng như tình trạng của cả 8 nhà đợt này (mục A5).

B. Đơn đặt trùng CS-A9DG — và miếng vá hai đầu 18/09 → 21/09

B1. Nguyên nhân gốc: ChicStay quên đệm dọn của chính mình

Ngày 18/09 một khách đặt được phòng 19:00–21:00 trong khi phòng đó đã có khách Gohost nhận lúc 21:00 (đặt từ 15/09, trước đơn ChicStay ba ngày). Dựng lại mốc hôm đó:

00:00 – 01:30   CSR08910 (khách đêm trước ra 00:30 + dọn)
06:30 – 18:00   CSR08888 ở
18:00 – 19:00   dọn phòng
19:00 – 21:00   CS-A9DG  ← khách ChicStay đặt lúc 10:59 ngày 18/09
21:00 – 22:00   cần dọn phòng   ✗ nhưng 21:00 khách CSR08727 đã nhận

ChicStay hỏi chicdata “19:00–21:00 có bận không?” và chicdata trả lời đúng: trống — chicdata đã cộng đủ 1 giờ dọn sau mỗi khách Gohost. Chỗ hụt là ChicStay không hỏi thêm 1 giờ dọn sau đơn của chính nó; nếu hỏi “19:00–22:00” thì đơn đã bị chặn. Không phải lỗi của Bum, cũng không phải lỗi dữ liệu chicdata.

B2. Miếng vá: khoá thêm 1 giờ ở CẢ HAI ĐẦU

Yêu cầu vận hành 18/09 — “phòng 2–3h thì bận 1–4h” — áp cho mọi phòng của mọi nhà, thay vì chỉ cộng sau giờ trả theo cấu hình từng nhà (trước đó 281/511 phòng để 0 phút).

• start_at = giờ nhận − 60, end_at = giờ trả + max(60, cấu hình nhà); block_id vẫn tính trên khoảng GỐC nên danh tính khoảng không đổi.
• Cột mới inventory_blocks.cleaning_before_minutes (migration 004, đã chạy production); /v1/rooms thêm checkin_at để còn trả được giờ nhận thật.
• Mô phỏng guardrail mass-block của ChicStay trên dữ liệu thật: phòng bận nhất sau khi cộng là 43% cửa sổ (ngưỡng 95%) — không nhà nào bị bỏ qua.
• Dashboard tô hổ phách cả hai đầu, bảng chi tiết tách Khoá từ / Dọn trước với Nhận/Trả là giờ khách — trước đó đầu thanh 16:30 đọc ra “khách tới 16:30” trong khi PMS ghi 17:30.

C. Đồng bộ lịch — hai kiểu sổ mới, ba lỗi hạ tầng 13 commit · 673 test

C1. Gohost chỉ giữ MỘT phiên cho mỗi người đăng nhập

Hai lỗi chồng nhau: phiên cache không mang cookie sang client của lượt sau nên lời gọi đầu luôn 419 rồi đăng nhập lại; và Lela mượn credential của Bum nhưng phiên giữ theo tài khoản nên hai bên đá phiên nhau mỗi phút. Số đo production 17–18/09: 1436/1441 lượt của Bum và 1437/1441 của Taphouse đều là session_renewed — gần như 100% lượt chạy phải đăng nhập lại.

Nay giữ phiên theo chủ credential, có khoá cho lượt chạy song song, chụp/nạp nguyên cookie jar. Đo lại với Gohost thật: 10 lượt Bum+Lela xen kẽ và song song → 1 lần đăng nhập, 0 session_renewed, số khoảng bận không đổi.

C2. Hai bố cục sổ mới

• Miu Homestay — sheet khai link Google nhưng thực ra là file Office (rtpof=true), Sheets API không đọc được. Tải qua Drive API rồi đọc bằng openpyxl, trả đúng dạng ô như grid() để chữ ký bố cục và reader chạy chung một đường. Ngày giờ ở nằm lẫn trong ghi chú tự do, chỉ đọc phần sau chữ “in”; không chắc thì khoá thừa (out không rõ = 24 tiếng). Soát tay 61/61 dòng của file thật khớp.
• DEMO Inn&Ine — sổ ghi ngày nhận/ngày trả, không có cột giờ. Qua đêm lấy giờ chuẩn của cơ sở; theo giờ thì tìm khung ở ba chỗ sổ thật hay ghi; đọc không ra hoặc giờ ngược thì khoá cả ngày lẫn đêm, không đoán. Đối chiếu từng dòng 17/09: 23/23 khoảng khớp, 0 thừa.

C3. Ba lỗi hạ tầng đo tận nơi

Deploy bản vá sync: push đúng commit 9c6f5a0 lên main, CI room-state xanh, /health trả đúng 9c6f5a0. Lượt sync đầu trên bản mới: 16/16 tài khoản chạy, 15 OK, chỉ sun_sheet PARTIAL — nhưng nó PARTIAL ở mọi lượt kể cả trước deploy. Không nhà nào bị hạ nhầm xuống “chưa biết”.

D. ChicStay backend — thiết kế lại phần sync phòng mới là thiết kế, chưa apply code

Phần việc của mình ở repo chicstay-backend tuần này chỉ là sync phòng: đưa hẳn bộ đồng bộ lịch từ chicdata về trong backend, chạy trên một Neon dev branch. Đã viết reports/chicstay-calendar-sync-architecture.html và chốt xong thiết kế với đội — chưa viết spec vào repo, chưa apply một dòng code nào.

Điểm xuất phát là hai đơn thật: CS-A9DG (mục B) và CS-8D2R — phòng bugalow của ALÀ HOMESTAY, đặt đêm 21/09, phòng này chưa map PMS nên backend coi là not_enforced và vẫn nhận đơn. Cùng một gốc: nguồn lịch và chỗ bán phòng đang nằm ở hai hệ.

Bốn nguyên tắc

• Backend là nguồn sự thật bán phòng — chicdata vẫn là nguồn catalog/onboarding nhưng thôi làm hop bắt buộc trong đường booking.
• Fail-closed cho instant, fail-open cho request — không kiểm được PMS thì không được bán instant; vẫn có thể tạo yêu cầu để ops/host xác nhận.
• Khoảng bận là nguồn thật, “trống” là suy luận — một hàm AvailabilityService.check_window() duy nhất thay vì ba nơi hiểu khác nhau.
• Adapter chỉ dịch dữ liệu, không quyết định nghiệp vụ.

Ba luật vận hành đã chốt

• Cron 1 phút bắn thẳng PMS đối tác, toàn bộ tài khoản. Đúng bằng nhịp chicdata đang chạy hôm nay nên tải lên PMS chủ nhà không tăng — chỉ đổi chỗ xuất phát, và bỏ được /v1/rooms đứng giữa.
• Trước khi tạo booking thì force gọi thẳng lấy dữ liệu mới nhất — bỏ dedupe TTL. Đề xuất cache 20–30s ban đầu mâu thuẫn trực tiếp với yêu cầu này nên đã bỏ, thay bằng single-flight: mười khách cùng bấm đặt trong một nhà → một lượt adapter.fetch đang bay, chín người kia chờ đúng lượt đó rồi dùng kết quả của nó. Khác dedupe ở chỗ dedupe trả dữ liệu cũ trong cửa sổ TTL, còn single-flight trả kết quả của lượt gọi vừa xảy ra. Ca test mới trong test_booking_external_conflict.py: mười request đồng thời → đúng một adapter.fetch, và cả mười cùng thấy dữ liệu của lượt đó.
• Timeout theo từng provider, không dùng một con số chung, luôn fail-open kèm cờ degraded. gsheet/dayladau nhanh; gohost phải đăng nhập — phiên nằm trong Redis nên lượt sau mới rẻ, còn lượt đầu sau khi phiên hết hạn thì phải chấp nhận chậm hoặc bỏ live check.
• Adapter vốn async, Django thì không: cron asyncio.gather lấy toàn bộ tài khoản song song, gom xong mới ghi DB đồng bộ một lượt; đường booking cũng vậy — asyncio.run một lượt fetch, ghi overlay, rồi mới vào transaction giữ chỗ. Adapter port sang gần như không phải sửa. Các GET/search/listing vẫn đọc DB overlay như cũ.

Năm quyết định chờ đội chốt

• Phòng không có nguồn lịch có được bán instant không (đề xuất: không, cho REQUEST nếu còn muốn bán).
• Stale / fetch failed xử thế nào (đề xuất: không tạo booking confirmed).
• Cột khai tay booking_confirmation_method còn là sự thật hay chỉ là nhãn.
• Đã thu tiền thì có bắt buộc ghi ngược PMS không.
• Nơi lưu DB cho bản dev (đề xuất Option B: thêm InventorySource/InventoryRoomMapping, giữ ExternalRoomState/ExternalBusyInterval làm read model booking).

Để khỏi hiểu nhầm khi đọc git log: 29 commit tính năng của chicstay-backend tuần này (engine booking thêm giờ, quy trình xác nhận check-in, Control Tower, ChicAI) là của đội dev ChicStay. Phần của mình là review và gộp 4 PR, cộng với bản thiết kế sync phòng ở trên.

E. Số đo production 21/09, lấy thẳng từ DB

+29 phòng nối trong tuần: 17 qua Gohost (Lela 6 phòng chạy thật sau khi vá phiên; Bum 404 Bưởi 9 và 68 CG 2 qua “mã móc lịch”) và 12 qua Google Sheet (Miu 8, DEMO Inn&Ine 4). Kiểm lại: cả 6 phòng Lela và cả 11 phòng mã móc đều đang có khoảng bận thật — hai việc treo từ tuần trước đã chạy.

F. Rủi ro đang mở

G. Việc khác trong tuần

• Custom Audience từ 3 group Facebook: lấy user id + tên + thông tin hiển thị của 1.000 thành viên, xuất fb-audience-value-based.csv 995 người đúng định dạng Meta, kèm fb-members.csv giữ nguyên 1.000 dòng gốc. File để ở Downloads, không đưa vào git để dữ liệu cá nhân không bị commit nhầm. Chờ quyết: lưu vào DB chicdata mới trên Neon hay trên Postgres 42.96.11.166.
• thueplayer.vn — bộ thu mới xong trọn: backend là Spring Boot (api.foxnagi.com), ba endpoint /non-secure/* mở công khai, không mã hoá thân request như PlayerDuo. Thu về 20 game, 38 player (site còn mới), xuất Excel 3 sheet cho BA/BD đúng khuôn PlayerDuo, kèm README. Review đòi đăng nhập nên bỏ qua.
• lita.gg — dừng ở cổng: đã dựng lại bộ ký request từ module WASM của site (l-sign), signer trong repo khớp reference, nhưng gateway APISIX h-api.lita.game vẫn trả 401. Đã đóng gói signer + README để lần sau bắt request thật từ browser là chạy tiếp được.
• Tài liệu API chicdata (173 endpoint gộp về một file README.md) vẫn chưa commit từ tuần trước.

Việc tuần tới

• Chốt hướng xử lý đệm dọn đầu giờ (B3) — thứ vận hành đang chạm vào hằng ngày.
• Chốt 5 quyết định ở mục D, viết spec vào docs/superpowers/specs/ rồi mới dựng schema + native syncer trong chicstay-backend.
• Ẩn 6 host mới; xin ảnh cho Blue Diamond; nhờ BD xin SUN HOMESTAY kéo dài bảng lịch.
• Push 6 commit còn lại trên nhánh onboard.
• Dọn nốt nhóm cơ sở chưa nối lịch — 52/109 cơ sở vẫn chưa có phòng nào nối PMS.
• Quyết nơi lưu dữ liệu audience Facebook rồi nạp; theo dõi Dayladau.