Xử lý sự cố

Biểu đồ trắng trơn hoặc báo lỗi WebGL

Biểu đồ được vẽ bằng WebGL. Nếu trình duyệt hoàn toàn không tạo được ngữ cảnh WebGL, biểu đồ sẽ báo rằng nó không khởi tạo được và đề nghị bạn cập nhật trình duyệt hoặc bật tăng tốc phần cứng — hai bước đó chính là cách khắc phục. Nếu ngữ cảnh đồ họa bị mất về sau, ví dụ sau khi GPU khởi động lại, một tab bị hủy, hoặc thiết bị di động vừa được đánh thức, biểu đồ sẽ báo rằng việc dựng hình đang tạm dừng và sẽ tiếp tục khi GPU hồi phục. Việc khôi phục là tự động: khi trình duyệt khôi phục ngữ cảnh, biểu đồ dựng lại tài nguyên GPU và tải lên lại các nến hiện tại, nên không cần tải lại trang. Nếu chính việc dựng lại thất bại, biểu đồ vẫn tạm dừng và lỗi được ghi vào console trình duyệt.

Trình duyệt của bạn phải cung cấp những gì

Biểu đồ nến và heatmap được vẽ trên một ngữ cảnh WebGL2. Bộ dựng hình yêu cầu canvas cấp riêng webgl2 và ném lỗi khi trình duyệt không trả về gì, đó chính là lúc biểu đồ báo rằng WebGL không khởi tạo được và gợi ý cập nhật trình duyệt hoặc bật tăng tốc phần cứng. Không có đường vẽ bằng phần mềm nào cho chính các cây nến — lớp chú thích dùng một canvas 2D thông thường, nhưng không có WebGL2 thì chuỗi giá hoàn toàn không hiển thị. Vì vậy một trình duyệt chỉ hỗ trợ thế hệ WebGL đầu tiên, hoặc chạy với tăng tốc bị tắt, sẽ cho ra một biểu đồ trắng kèm đúng thông điệp đó.

Khi một ngữ cảnh đã được tạo rồi sau đó bị mất — trình điều khiển GPU khởi động lại, một tab nền bị hủy, một thiết bị di động vừa được đánh thức — biểu đồ hủy cách xử lý mặc định của trình duyệt đối với sự cố mất ngữ cảnh, chính điều đó mới làm cho việc khôi phục tự động trở nên khả thi, và chuyển sang trạng thái tạm dừng. Khi được khôi phục, nó dựng lại tài nguyên GPU, vô hiệu hóa phiên bản bộ đệm của mình để mọi cây nến được tải lên lại, rồi quay lại vẽ. Mỗi bước để lại một dòng trong console trình duyệt với tiền tố [WebGLChart]: một dòng cho sự cố mất ngữ cảnh, một dòng cho lần dựng lại thành công, và một dòng lỗi nếu việc dựng lại thất bại. Ba dòng đó là bằng chứng nhanh nhất để đưa vào một báo cáo về biểu đồ trắng.

Chuyển hướng đăng nhập, lời mời nâng cấp và tính năng bị tắt

Mở một trang được bảo vệ khi đã đăng xuất sẽ đưa bạn tới trang đăng nhập với đích đến được giữ lại, và đưa bạn quay về đó sau đó; cùng tình huống trên một yêu cầu API sẽ trả lời 401 với UNAUTHORIZED. Nếu bạn đã đăng nhập nhưng gói của bạn không bao phủ trang đó, bạn được chuyển hướng tới trang Upgrade với bậc cần có trong chuỗi truy vấn, và yêu cầu API tương đương trả lời 402 với PAYMENT_REQUIRED kèm khóa tính năng. Trò chuyện trực tiếp bị chặn theo cùng cách — ở bậc preview, trang Support hiển thị một lời kêu gọi nâng cấp thay vì cửa sổ trò chuyện. Một tính năng bị người vận hành tắt sẽ trả lời 503 với KILL_SWITCH và một header Retry-After.

Bị khóa, bị ép và bị trễ — những gì không phải là lỗi

Có hai tín hiệu hình ảnh nghĩa là "gói của bạn không bao gồm phần này", và không cái nào là lỗi. Một bề mặt bị chặn sẽ được phủ bởi lớp ổ khóa, lớp này chặn cả cú nhấp chuột lẫn thao tác bằng bàn phím và mở hộp thoại nâng cấp thay vì liên kết bên dưới. Một widget dữ liệu hiển thị một phần thì nhận một viên thuốc màu vàng nội tuyến — dùng ở nơi dữ liệu có mặt nhưng bị giảm bớt, chẳng hạn một nhịp giá bị trễ hoặc chiều sâu lịch sử bị ép ngắn. Nếu một biểu đồ hiển thị ít thanh hơn bạn mong đợi và mang viên thuốc đó, lịch sử đã bị rút ngắn có chủ đích chứ không phải bị mất.

Yếu tố thời điểm giải thích quan sát thứ ba. Một cổng cố ý giữ trạng thái chưa xác định cho tới khi quyền của bạn được tải xong: trước đó nó bị ẩn và vô hiệu, nên người dùng trả phí không bao giờ thấy một trạng thái khóa lóe lên trước khi mở. Hệ quả nhìn thấy được là một ô bị chặn có thể trống trong chốc lát ngay sau khi trang tải xong. Trên máy chủ, cùng chính sách đó trả lời các yêu cầu API bằng 402 kèm một payload nêu khóa tính năng và bậc cần có, trong khi một lần điều hướng bằng trình duyệt được chuyển hướng tới trang Upgrade với nguồn, đường dẫn gốc và bậc cần có trong chuỗi truy vấn — đó là lý do trang Upgrade có thể nói chính xác bạn đã cố mở thứ gì.

Các mã lỗi mà một phản hồi API mang theo

Mọi phản hồi từ API của chính ứng dụng đều có một hình dạng cố định. Một phản hồi thành công mang success: true, một payload data và một dấu thời gian. Một phản hồi thất bại mang success: false và một đối tượng error chứa một code máy đọc được, một message người đọc được, và tùy chọn một target nêu trường bị lỗi, một đối tượng details với bối cảnh bổ sung, và một doc_url. Hãy trích dẫn code khi bạn báo cáo sự cố: code là ổn định, còn cách diễn đạt của message thì không. Có mười hai code tồn tại, và mỗi code gắn với đúng một trạng thái HTTP.

Hai hình dạng phản hồi nằm ngoài tập đó. Các endpoint đời cũ trả lời trong một phong bì cũ gồm code, msg, data và success, trong đó code là một chuỗi số được nhóm theo lớp: 10xxx cho vấn đề đầu vào, 20xxx cho xác thực, 30xxx cho phân quyền, 40xxx cho tài nguyên thiếu hoặc xung đột, 50xxx cho lỗi máy chủ và 60xxx cho các dịch vụ thượng nguồn. Các vấn đề về cơ sở dữ liệu được dịch lại trước khi tới tay bạn: mất kết nối trở thành 503 với "Database temporarily unavailable", một truy vấn vượt giới hạn thời gian trở thành 504 với "Request timed out", một bản ghi trùng trở thành 409, và vi phạm ràng buộc trở thành 400. Hai trường hợp đầu đáng để thử lại; hai trường hợp sau sẽ lặp lại cho tới khi đầu vào thay đổi.

• BAD_REQUEST — 400. Yêu cầu bị dị dạng. Hãy kiểm tra các tham số bạn đã gửi.
• VALIDATION_ERROR — 400. Một đầu vào không qua được kiểm tra; phản hồi nêu tên nó trong target.
• UNAUTHORIZED — 401. Không có phiên hợp lệ. Hãy đăng nhập rồi lặp lại yêu cầu.
• PAYMENT_REQUIRED — 402. Đã đăng nhập, nhưng gói không bao phủ phần này. details mang featureKey, requiredTier và, với các cổng theo domain, requiredDomain.
• FORBIDDEN — 403. Đã xác thực nhưng không được phép. Lý do chính xác được cố ý giữ ở phía máy chủ.
• NOT_FOUND — 404. Không có tài nguyên nào ở địa chỉ đó.
• CONFLICT — 409. Tài nguyên đã thay đổi bên dưới bạn, hoặc đã tồn tại. Hãy tải lại và thử lại.
• PAYLOAD_TOO_LARGE — 413. Phần thân yêu cầu vượt quá kích thước được chấp nhận.
• RATE_LIMITED — 429. Quá nhiều yêu cầu. Phản hồi mang Retry-After, X-RateLimit-Limit và X-RateLimit-Remaining; các endpoint AI có ngân sách riêng và trả lời bằng code riêng AI_RATE_LIMITED.
• INTERNAL_ERROR — 500. Một lỗi máy chủ ngoài dự kiến. Hãy báo cáo kèm Error ID của bạn.
• UPSTREAM_ERROR — 502. Một dịch vụ mà endpoint phụ thuộc đã thất bại. Hãy thử lại sau.
• SERVICE_UNAVAILABLE — 503. Tạm thời không khả dụng. Lưu ý rằng một tính năng bị tắt có chủ đích dùng một phần thân 503 khác, mô tả bên dưới.

Kill switch: ai tắt một tính năng, và trong bao lâu

Một kill switch là công tắc tắt cho một tính năng cụ thể, do đội ngũ Athenum vận hành chứ không phải bạn, và đó là lý do một trang có thể không tiếp cận được trong khi phần còn lại của ứng dụng vẫn khỏe mạnh. Hai tình huống khác nhau tạo ra cùng một 503. Nếu tính năng bị tắt vì phần backend của nó chưa được phát hành, trang lỗi ghi "Coming Soon" và giải thích rằng tính năng đang được phát triển. Nếu một người vận hành tắt một tính năng vốn đang chạy, trang ghi "Temporarily Unavailable". Cả hai phản hồi đều tự định danh bằng code KILL_SWITCH và một tên tính năng công khai ổn định như funding-heatmap hay cme-detector.

Phản hồi cho bạn biết phải chờ bao lâu. Mỗi công tắc mang giá trị Retry-After riêng: 60 giây cho Funding Heatmap, 1800 giây cho CME Detector, và 300 giây cho bất cứ thứ gì không có thiết lập rõ ràng. Bên gọi API nhận cùng thông tin đó dưới dạng application/problem+json, bao gồm một cờ defaultKilled phân biệt trường hợp chưa xây xong với trường hợp do người vận hành tắt. Bản thân 503 không bao giờ được lưu đệm, và các phản hồi thành công trên những endpoint có thể tắt bị giới hạn đệm ở mười giây, nên một lần bật tắt công tắc sẽ tới tay bạn nhanh chóng; một bộ đệm dùng chung vẫn có thể phục vụ câu trả lời cũ trong khoảng mười lăm giây sau khi công tắc đổi trạng thái.

Một route bị tắt thường không thể tới bằng cách bấm chuột. Các route bị một công tắc chặn hoàn toàn sẽ bị lọc khỏi các thẻ ở trang chủ và bị ẩn khỏi bảng lệnh, nên 503 chủ yếu chỉ được thấy bởi những người dùng dấu trang, liên kết trực tiếp hoặc API. Không phải công tắc nào cũng chặn một route: một số công tắc thay đổi hành vi ngay tại chỗ, đó là lý do một tính năng có thể bị ảnh hưởng mà không trang nào trả về 503. Các trang kill switch không mang Error ID, vì phản hồi là một quyết định có chủ đích chứ không phải một sự cố, và không có định danh nào được bịa ra để lấp vào ô đó.

Bảo trì toàn site so với một tính năng đơn lẻ bị lỗi

Một cửa sổ bảo trì đã lên kế hoạch trông khác mọi loại lỗi khác. Thay vì trang lỗi thông thường, bạn nhận được một tài liệu độc lập có tiêu đề "We'll be back soon", không có điều hướng, không có Error ID và không có liên kết hỗ trợ. Nó được phục vụ với HTTP 503 và một Retry-After một giờ. Trang này hoàn toàn tự chứa — kiểu dáng và logo được nhúng sẵn, và nó không gọi mạng — nên nó vẫn hiển thị được khi backend, cơ sở dữ liệu và analytics đều không tiếp cận được. Nó cũng được đánh dấu không cho lập chỉ mục, nên các công cụ tìm kiếm coi sự cố này là tạm thời.

Cổng này cố ý hẹp. Nó chỉ thay thế các yêu cầu trang từ trình duyệt: các yêu cầu GET hoặc HEAD xin HTML. Các lệnh gọi API dưới /api/ đi thẳng qua, cũng như các endpoint kiểm tra sức khỏe container và mọi yêu cầu xin script, kiểu dáng hoặc phông chữ. Một hệ quả đáng biết: trong lúc bảo trì, một client API hoặc một tích hợp nhúng có thể tiếp tục hoạt động bình thường trong khi trình duyệt hiển thị trang bảo trì. Nếu bạn thấy "We'll be back soon" thì cả site bị ảnh hưởng; nếu bạn thấy một trang lỗi 503 nêu tên một tính năng, chỉ tính năng đó bị ảnh hưởng.

Đọc một bảng trống: huy hiệu nêu tên lỗi

Các bảng trên những trang macro mang một huy hiệu nhỏ ở góc, và huy hiệu đó là cách nhanh nhất để phân biệt một sự cố với một nguồn dữ liệu yên ắng. Năm trạng thái huy hiệu mô tả dữ liệu thật, và hai trạng thái mô tả chính cái bảng đó. Vì huy hiệu được suy ra từ chính các quy tắc độ tươi mà bảng dùng để vẽ, nó không thể tuyên bố một trạng thái mà dữ liệu không ủng hộ: một bảng không có gì để hiển thị không bao giờ bị gắn nhãn STALE, và một giá trị bị thiếu không bao giờ được thay bằng một con số thế chỗ.

Các lớp vỏ ở cấp bảng bổ sung một tầng thông tin thứ hai. Một lần tải đầu tiên đang chạy sẽ hiển thị khung xương không có kết luận và không có chữ. Một phép đọc thất bại ở tầng truyền tải sẽ hiển thị một thẻ lỗi với dòng chữ "Fleet read failed — the source may still be live. Retry to reload." cùng một nút thử lại — nguồn rất có thể vẫn khỏe mạnh, và thử lại là phản ứng đúng. Một phép đọc thành công nhưng không trả về hàng nào sẽ hiển thị "Awaiting Fleet-Bridge" với huy hiệu UNAVAILABLE. Hai thứ đó trông giống nhau nhưng có nghĩa ngược nhau: cái thứ nhất là vấn đề kết nối bạn có thể thử lại, cái thứ hai nghĩa là chuỗi dữ liệu chưa bắt đầu chảy.

Các bảng TradeFI báo lý do bằng lời thay vì bằng huy hiệu. Khi nhà cung cấp dữ liệu thất bại, bảng nói rằng dữ liệu tạm thời không khả dụng. Khi nhà cung cấp trả lời mà không có gì, bảng nói rằng không có dữ liệu cho symbol đó. Sở hữu tổ chức có thêm một trường hợp thứ ba: một ghi chú giải thích rằng chế độ xem này là tập con các tổ chức được theo dõi chính thức và mang tính đại diện chứ không phải toàn diện — đó là một lời nêu phạm vi, không phải một lỗi. Danh sách công ty cùng ngành cũng hành xử tương tự và nêu tên một nguồn không mặc định trong một ghi chú phía trên bảng khi một nguồn như vậy được dùng.

• LIVE — một quan sát trong ngày hoặc thời gian thực nằm trong nhịp mong đợi của nó.
• EOD — một phiên đóng cửa trung thực cho chuỗi theo ngày, tuần, tháng hoặc quý.
• STALE — một giá trị thật, nhưng cũ hơn nhịp cập nhật mong đợi của chuỗi.
• FALLBACK — dữ liệu đệm tốt nhất đã biết gần nhất, rõ ràng không phải giá trị hiện tại.
• MODEL — một phép suy tính toán hoặc một cấu trúc do Athenum dựng, không phải một quan sát trực tiếp.
• UNAVAILABLE — bảng đang ở trạng thái lỗi và không có gì được hiển thị.
• LOADING — lần tải đầu tiên vẫn đang chạy và độ tươi chưa được xác định.

Báo cáo sự cố: Error ID của bạn

Khi một yêu cầu thất bại, trang lỗi hiển thị trạng thái HTTP, một tiêu đề ngắn và — khi có sinh ra — một Error ID. Định danh đó được đúc riêng cho sự cố cụ thể của bạn và được đính kèm vào báo cáo lỗi đã ghi lại, nên bộ phận hỗ trợ có thể tìm đúng trường hợp của bạn. Hãy dùng nút Copy bên cạnh nó, rồi chọn “Trò chuyện với hỗ trợ”: liên kết sẽ mang Error ID sang trang Support. Khi báo cáo, hãy đưa vào Error ID, địa chỉ trang và việc bạn đang làm. Không phải lỗi nào cũng có Error ID — với một tính năng bị tắt tạm thời, không có giá trị thế chỗ nào được bịa ra, nên trường đó đơn giản là vắng mặt.

Error ID của bạn đi đâu sau khi bạn sao chép nó

Định danh trên trang lỗi được đúc trên máy chủ, mỗi sự cố một lần, tại thời điểm lỗi được bắt. Máy chủ ghi một mục log chứa định danh đó cùng với trạng thái HTTP, tên lỗi, đường dẫn yêu cầu, phương thức yêu cầu và một dấu thời gian; trong môi trường production, mục log cố ý bỏ qua stack trace và chi tiết nội bộ. Cùng định danh đó được đính vào sự cố gửi tới hệ thống theo dõi lỗi, nên bộ phận hỗ trợ có thể đối chiếu bản sao id của bạn với lỗi đã ghi nhận. Các yêu cầu chỉ đơn giản chạm vào một trang không tồn tại là ngoại lệ: chúng vẫn nhận một định danh, nhưng không được chuyển tiếp tới hệ thống theo dõi lỗi.

Những gì trình duyệt nhận lại được cố ý làm mỏng — một thông điệp chung chung cộng định danh — để không có chi tiết nội bộ nào rò rỉ qua trang. Bấm "Trò chuyện với hỗ trợ" sẽ mang định danh đi tiếp: liên kết mở trang Support với chủ đề sự cố, Error ID và một yêu cầu mở cửa sổ trò chuyện, thay vì khởi chạy một widget trò chuyện ngay trên trang bị lỗi. Nếu nút Copy có vẻ không làm gì, thì việc ghi vào clipboard đã bị từ chối — điều này xảy ra trên các origin không an toàn hoặc khi quyền clipboard bị từ chối — và lỗi được ghi vào console trình duyệt; trong trường hợp đó hãy bôi đen định danh bằng tay.

Việc trò chuyện trực tiếp có thực sự khả dụng trên trang Support hay không phụ thuộc vào ba lần kiểm tra thực hiện trước khi trang hiển thị. Trò chuyện đòi hỏi một gói trả phí: ở bậc preview, trang hiển thị lời mời nâng cấp thay vào đó. Trò chuyện cũng bị giữ lại khi công tắc trình nhắn tin hỗ trợ đang tắt, và khi yêu cầu cần một sự đồng ý chưa được ghi nhận — đó là trường hợp của các yêu cầu trông có vẻ đến từ châu Âu, Anh hoặc Thụy Sĩ, và của các yêu cầu hoàn toàn không mang tín hiệu quốc gia nào, vì phép kiểm tra này thất bại theo hướng đóng. Trong mọi trường hợp đó, trang vẫn cung cấp email và cộng đồng Discord, và hai kênh này luôn có mặt bất kể gói nào.

Cần kiểm tra gì trước khi bạn báo cáo sự cố

Phần lớn những gì bộ phận hỗ trợ sẽ hỏi bạn đều đã hiển thị sẵn trên màn hình. Các bước kiểm tra dưới đây mất chưa tới một phút và biến "nó hỏng rồi" thành một báo cáo có thể xử lý được. Hãy làm từ ngoài vào trong — cả site, rồi tới trang, rồi tới bảng — vì mỗi tầng có một chủ sở hữu khác nhau và một cách sửa khác nhau. Không mục nào ở đây cần tới công cụ dành cho nhà phát triển, ngoại trừ hai mục có nhắc đến chúng một cách rõ ràng.

• Xác định phạm vi. Mọi trang đều bị ảnh hưởng, một trang, hay một bảng bên trong một trang vẫn hoạt động bình thường? "We'll be back soon" nghĩa là cả site; một trang 503 nêu tên một tính năng nghĩa là chỉ tính năng đó.
• Đọc nguyên văn dòng chữ. "Coming Soon" và "Temporarily Unavailable" là hai tình huống khác nhau dù cả hai đều là 503, và hai dòng chữ trên bảng "Fleet read failed" và "Awaiting Fleet-Bridge" có nghĩa ngược nhau.
• Tìm một huy hiệu. LOADING, STALE, FALLBACK và UNAVAILABLE mỗi cái mô tả một tình trạng khác nhau, và một ổ khóa hoặc viên thuốc vàng nghĩa là giới hạn của gói chứ không phải một lỗi.
• Thử lại một lần sau khi chờ. Các phản hồi tạm thời tự nêu cửa sổ thử lại của chúng trong header Retry-After, xem được trong bảng network của trình duyệt; thử lại sớm hơn thường sẽ nhận đúng câu trả lời cũ.
• Với một biểu đồ trắng, hãy mở console trình duyệt và tìm các dòng có tiền tố [WebGLChart], rồi xác nhận trình duyệt là bản mới và tăng tốc phần cứng đang bật.
• Sao chép Error ID nếu có hiển thị. Nếu nút Copy không làm gì, hãy bôi đen bằng tay — việc ghi vào clipboard có thể bị trình duyệt từ chối.
• Ghi lại địa chỉ trang, thời điểm, và việc bạn đã làm ngay trước khi lỗi xảy ra. Error ID định danh sự cố; ba thứ đó định danh điều bạn đang muốn đạt được.

Các mã lỗi của collector

Collector dữ liệu futures gắn cho mỗi lỗi một mã ổn định, và mã đó xuất hiện trong dấu ngoặc vuông ở bất cứ đâu văn bản lỗi được hiển thị hoặc ghi log. Đây là các định danh phía backend: nhìn thấy một mã trong câu trả lời của bộ phận hỗ trợ hoặc trong một ghi chú trạng thái sẽ cho bạn biết giai đoạn nào đã thất bại, và collector đã thử lại, chuyển sang nguồn khác, hay bỏ cuộc.

Các mã lỗi của Volume Delta

Endpoint Volume Delta trả về một code có tiền tố VDLT_ và một gợi ý. Các lỗi có thể thử lại là lỗi thoáng qua — cùng một yêu cầu có thể thành công ngay sau đó; các lỗi còn lại đòi hỏi chính yêu cầu phải thay đổi.

Vẫn chưa xong

Hãy liên hệ Support từ bên trong ứng dụng. Hiện chưa có mục tiêu mức dịch vụ, số liệu uptime hay thời gian phản hồi được đảm bảo nào được công bố, nên trang này không nêu ra con số nào.