Giữ chat hoạt động khi điện thoại ngủ

Agent của Mythex có thể làm việc vài phút cho một yêu cầu, và bạn có thể đang theo dõi từ điện thoại — thứ sẽ khóa màn hình, chuyển app và đổi mạng trong lúc nó làm việc. Hai lỗi đã làm mọi thứ trục trặc. Một lỗi khiến chat coi mọi tín hiệu “trang đã hiển thị trở lại” là bằng chứng rằng kết nối đã chết, và lặp lại mãi cho đến khi nó đứng yên ở “Đang kết nối…”. Lỗi còn lại là một điện thoại đã ngủ suốt lượt trả lời đầu tiên của một chat mới, khi quay lại chỉ thấy vài mảnh đầu của câu trả lời, cho đến khi làm mới trang thủ công. Cả hai đều đã được sửa.

Chat theo dõi một lượt đang chạy như thế nào

Trong lúc agent làm việc, chat giữ một stream mở từ máy chủ của chúng tôi: mỗi bước — một suy nghĩ, một lần gọi công cụ, một đoạn của câu trả lời — đến dưới dạng một sự kiện. Nếu stream bị đứt, chat sẽ kết nối lại và máy chủ phát lại các sự kiện gần đây từ một bộ đệm giữ 120 giây cuối. Khi lượt kết thúc, chat cũng yêu cầu máy chủ lịch sử đã lưu và đối chiếu những gì nó đã hiển thị với những gì đã được lưu. Bước cuối cùng đó bắt được bất cứ điều gì stream đã bỏ lỡ.

Để phân biệt một kết nối còn sống với một kết nối đã chết khi chưa có gì xảy ra, máy chủ gửi một “ping” nhỏ mỗi 15 giây.

Lỗi 1: thức dậy làm chết một stream còn khỏe

Trình duyệt báo cho trang biết khi nó hiển thị trở lại: sau khi chuyển tab, sau khi màn hình mở khóa. Chúng tôi dùng tín hiệu đó như một gợi ý để kiểm tra kết nối — và trên thực tế là hủy stream rồi kết nối lại, với giả định rằng nó đã chết trong lúc bị ẩn.

Trên điện thoại và trong các trình duyệt nhúng, các sự kiện này xảy ra thường xuyên hơn nhiều so với việc stream bị chết — mỗi lần chuyển tab, mỗi lần mở khóa, và trong một số trình duyệt nhúng là vài giây một lần. Mỗi sự kiện như vậy làm hủy một stream hoàn toàn khỏe mạnh. Chat kết nối lại, phát lại, bị hủy lần nữa, và cuối cùng đứng yên ở “Đang kết nối…”. Sau đó nó báo rằng lượt đã kết thúc trong khi agent vẫn đang làm việc.

Cách sửa: đánh giá stream qua việc nó có đang truyền dữ liệu hay không

Giờ chat ghi lại thời điểm mà stream của mỗi dự án lần cuối nhận được bất cứ thứ gì — cả sự kiện lẫn ping 15 giây. Tín hiệu “hiển thị trở lại” chỉ hủy một stream đã im lặng suốt 25 giây: lâu hơn khoảng thời gian ping cộng với một chặng mạng chậm, nên một stream còn sống sẽ không bao giờ rơi vào trường hợp này. Các bài kiểm thử xác nhận rằng một ping được tính là dấu hiệu còn sống, và một stream vừa ping không bị coi là đã chết.

Quy tắc chúng tôi rút ra: việc trang có hiển thị hay không nói lên điều gì đó về trang, chứ không phải về kết nối mạng. Hãy hỏi chính kết nối.

Lỗi 2: nửa câu trả lời sau khi điện thoại thức dậy

Lỗi này chúng tôi có thể tái hiện mỗi lần trên iOS simulator:

1. Bắt đầu một chat mới và gửi một yêu cầu mất một lúc.
2. Để điện thoại ngủ suốt quá trình build.
3. Quay lại sau khi lượt đã kết thúc và bộ đệm phát lại hai phút đã hết hạn.

Chat hiện vài khối đầu tiên của câu trả lời, được đánh dấu là đã xong — và cứ như vậy cho đến khi bạn làm mới trang.

Nguyên nhân

Một chat mới chưa có thread — tức là cuộc hội thoại đã lưu — cho đến khi tin nhắn đầu tiên tạo ra nó. Việc đó xảy ra bên trong hàm gửi, sau khi gửi đã kịp lấy bước đối chiếu, mà bước này vẫn nghĩ rằng chưa có thread. Vì vậy vào cuối lượt đầu tiên trong một chat mới, đối chiếu thấy không có thread và lặng lẽ thoát mà không yêu cầu gì.

Thường thì không ai để ý, vì stream đã truyền toàn bộ lượt rồi. Nhưng một điện thoại đã ngủ suốt lượt và quay lại sau khi bộ đệm phát lại 120 giây đã hết hạn thì không thể lấy các sự kiện còn thiếu từ stream — và bước đối chiếu lẽ ra phải lấp chỗ trống đó thì chưa bao giờ chạy.

Cách sửa

• Gửi báo cho bước đối chiếu biết lượt thuộc thread nào, nên lượt đầu tiên của một chat mới được đối chiếu như mọi lượt khác. Nếu khi câu trả lời về bạn đã mở một chat khác, kết quả sẽ bị bỏ đi thay vì hiển thị sai chỗ.
• Đối chiếu thất bại sẽ được thử lại. Một điện thoại thức dậy trên kết nối kém có thể thấy lượt đã kết thúc rồi lại không tải được nó. Điều đó giờ được ghi nhớ, và chat sẽ hỏi lại khi tab được hiển thị trở lại hoặc khi mạng có lại.
• “Đã làm việc trong” là trung thực. Mỗi câu trả lời cho biết agent đã làm việc bao lâu. Nếu tab chưa bao giờ nhận được thông báo kết thúc lượt từ máy chủ, trước đây nó sẽ tự điền con số đó theo đồng hồ của chính mình — đồng hồ đó tính từ lúc bấm Gửi cho đến khi điện thoại thức dậy, kể cả thời gian bị bỏ đi. Con số đó giờ được đánh dấu là ước tính, và sẽ được thay bằng thời lượng đã lưu khi lịch sử đến nơi.

Chúng tôi rút ra điều gì

• Kiểm thử trên thiết bị mà người dùng thực sự dùng, theo cách họ dùng. Cả hai lỗi đều nằm trong khoảng trống giữa “một stream đang hoạt động” và “một chiếc điện thoại trong túi”.
• Một phương án dự phòng không bao giờ chạy thì không phải là dự phòng. Bước đối chiếu tồn tại chính để bắt trường hợp này, nhưng nó lại âm thầm bỏ qua.
• Cũng hãy thử lại cơ chế phục hồi. Khoảnh khắc điện thoại thức dậy thường là lúc kết nối của nó đang ở tình trạng tệ nhất.
• Đừng trình bày phỏng đoán như sự thật. Một khoảng thời gian tính theo đồng hồ sai còn tệ hơn là không có gì; hãy gắn nhãn cho nó hoặc thay thế nó.

Công việc này cũng dọn dẹp một vài thứ bạn sẽ thấy trong lúc lượt đang chạy: các bước shell được gắn nhãn theo lệnh thực hiện công việc chứ không phải cd, ảnh chụp màn hình trong chat giữ góc trên bên trái của trang và vừa với cột, và một dự án mới nhận tên được tạo tự động mà không cần làm mới trang.

Nếu bạn đang xây một app cho điện thoại, các hướng dẫn về xây web app thân thiện với di động và app native so với progressive web app bao quát các kiến thức nền tảng. Thêm về chính chat có trong tài liệu về chat.