Đồng bộ lúc 6 giờ sáng, sao trang vẫn hiện giá hôm qua?

Mình có ba ngày đo, chẳng ngày nào đủ 24 tiếng. Xếp lại theo giờ thì chúng ghép thành một ngày khá trọn ở một trang so giá: lúc nó kéo giá về, lúc nguồn mới có giá, và lúc mình đo nhầm chỗ.

Trang này so giá điện thoại, laptop giữa mấy chục cửa hàng. Nó chẳng tự đi cào giá. Một dịch vụ dữ liệu khác cào mỗi ngày, ghi lại ngày cào cho từng cửa hàng, còn trang kéo bản mới về theo lịch. Trang hứa đúng một câu: giá hôm nay, nhiều cửa hàng, đặt cạnh nhau.

Số ngày 2/11 mình chép từ ghi chép sửa lỗi bên đó. Số ngày 10/11 và 11/11 mình đo bằng scripts/garden/catalogue-freshness-probe.ts, chỉ đọc dữ liệu công khai, chẳng cần khóa. Phần đo và bản nháp có AI làm cùng.

English: The sync ran at 6 a.m., so why did the site show yesterday's prices?.

02:05, mình đo nhầm máy

Ngày 10/11, hai giờ sáng. Một lượt chạy tự động của mảnh vườn này chạy phép kiểm của trang so giá, rồi ghi lại: "STALE, chậm 1 ngày, tệp của trang ở ngày 8/11". Dòng đó lọt vào danh sách việc cần làm như một số đo thật.

Phép kiểm đó trả lời cho cái máy nó đứng, mà nó đứng trên máy của mình. Nó lấy tệp mới nhất trong một thư mục, và thư mục đó nằm ở đâu thì tùy chỗ bạn gõ lệnh. Con số 8/11 là một bản sao cũ trên máy mình, chẳng nói gì về trang thật. Nên mọi số đo phía dưới đều đọc trang từ bên ngoài, qua mạng, như một người xem, và luôn in kèm giờ đo.

06:00, lượt đồng bộ báo xong

Lúc đưa trang lên, ghi chép triển khai chọn 06:00 cho job đồng bộ, kèm một dòng lý do: "sau khi nguồn cào xong". Sáng sớm, người ta chưa mở trang, dữ liệu mới về là vừa. Nghe hợp lý, và chẳng ai đo.

Ngày 2/11, lúc 06:01, người sửa lỗi đứng ngay trên máy chạy trang và nhìn job vừa xong: báo thành công, trả mã 0, kéo về 35.439 dòng. Ngày cào mới nhất bên nguồn lúc đó là 1/11. Job chẳng hỏng gì, nó chỉ chạy quá sớm, rồi giữ bản hôm qua cả ngày. Ai mở trang từ sáng tới tối đều thấy giá hôm qua, trên một trang mà cả lý do tồn tại là giá hôm nay.

07:45, nguồn mới có 6 cửa hàng

Sáng nay, 11/11, lúc 07:45: bên nguồn có giá ngày 11/11 cho 6 trên 43 cửa hàng, còn trang vẫn hiện 10/11. Lượt 06:00 vẫn chạy mỗi sáng, và vẫn về quá sớm.

Lịch mới vẫn giữ lượt 06:00, vì nó chẳng tốn gì, chỉ là nó chẳng gánh nổi một mình. Hôm nào nguồn xong sớm thì nó kịp. Hai ngày mình đo thì nó đều hụt.

11:06, nguồn có 19 cửa hàng, trang vẫn ở hôm qua

Ngày 10/11, lúc 11:06: 19 trên 43 cửa hàng có giá hôm nay bên nguồn, mà trang vẫn hiện 09/11. Nếu lịch còn như cũ, chỉ một lượt 06:00, trang sẽ giữ 09/11 tới tận sáng hôm sau, dù nguồn đã có giá mới từ trước trưa.

12:15, lượt chạy thứ hai

Phản xạ đầu tiên là dời 06:00 sang một giờ trễ hơn. Nhưng trễ hơn là mấy giờ? Hai lần đo ngày 2/11 chỉ nói nguồn xong ở đâu đó giữa 06:01 và 18:33. Chọn một giờ mới cũng chỉ là đoán lại lần nữa.

Nên bản sửa chẳng đoán giờ, mà thêm lượt chạy. Giữ 06:00, thêm 12:15 và 17:45. Nguồn xong lúc nào thì lượt kế tiếp sẽ kéo về, và khoảng người xem phải chịu giá cũ rút từ cả ngày xuống vài tiếng. Mỗi lượt ghi ra một tệp chừng 35 MB, máy giữ 7 tệp mới nhất, nên ba lượt một ngày vẫn chẳng tốn mấy chỗ.

Có một chi tiết nhỏ mình thích. Cái timer đó do một hệ thống triển khai khác viết ra, và lần triển khai nào cũng có thể viết lại nó. Nên hai giờ mới nằm trong một tệp drop-in riêng, chẳng sửa thẳng vào tệp gốc. systemd cộng dồn các dòng OnCalendar từ mọi tệp drop-in, nên lần triển khai sau có viết lại tệp gốc thì cả ba giờ vẫn còn. Cái giá là giờ chạy nằm ở hai chỗ, và bên sửa đã nhờ bên kia gộp lại cho khỏi lệch.

13:40, trang sang ngày mới, mà phép kiểm nói quá

ngày	giờ (+07)	cửa hàng có giá ngày đó bên nguồn	ngày trang hiện
10/11	11:06	19 trên 43	09/11
10/11	13:40	26 trên 43	10/11
11/11	07:45	6 trên 43	10/11
11/11	13:41	24 trên 43	11/11

Hai ngày, cùng một nhịp: buổi sáng trang còn ở hôm qua, đầu giờ chiều trang đã sang ngày mới. Giữa hai lần đo mỗi ngày, lịch chỉ có đúng một lượt là 12:15.

Nhưng nguồn chẳng xong vào một giờ nào cả. Giá về từng cửa hàng một, rải ra trong ngày. Lúc 13:40 ngày 10/11 vẫn còn 15 cửa hàng ở ngày 9/11, và 2 cửa hàng đứng im từ tháng 7 với tháng 9.

Bản sửa có kèm một phép kiểm nhỏ, chạy chừng 0,1 giây: so ngày mới nhất bên nguồn với ngày mới nhất trang đang giữ, rồi in fresh hoặc STALE, chậm N ngày. Lúc 13:40 nó sẽ in fresh, vì ngày mới nhất chỉ cần một cửa hàng là đủ, còn phần đuôi thì nó chẳng thấy. Bản probe mình viết từng in đúng chữ "fresh" khi 17 trên 43 cửa hàng chưa có giá hôm nay. Giờ nó in kèm số đếm, vì "26 trên 43" thật hơn "fresh".

May là trang chẳng dựa vào phép kiểm đó để nói với người xem. Trang một chiếc điện thoại ghi ngày dữ liệu cạnh từng giá: lúc mình mở, 11 giá ghi 10/11, 6 giá ghi 09/11, 1 giá ghi 31/10. Phép kiểm thì gói gọn, còn trang thì nói thật.

17:45, chỗ mình chưa đo tới

Lượt thứ ba chạy lúc 17:45. Điểm đo trễ nhất mình có là 18:33 ngày 2/11, và nó chẳng phải của mình: lúc đó nguồn đã sang ngày 2/11, còn trang vẫn giữ 1/11. Ba ngày mình đo chưa lần nào qua khỏi 14 giờ.

Nên mình chưa biết cửa hàng cuối cùng về lúc mấy giờ, chưa biết lượt 17:45 có kịp không, hay 12:15 có nên dời trễ hơn. Còn 2 cửa hàng đứng im mấy tháng nay thì mình chưa biết trang nên giấu đi, hay để đó cho người xem tự thấy ngày.