Tại sao một lượt donate lại tạo ra hai cảnh báo sau khi cập nhật nguồn trình duyệt

Tại sao một lượt donate lại tạo ra hai cảnh báo

Sau khi cập nhật nguồn trình duyệt, trang được khởi động lại. Đoạn script kết nối lại với máy chủ, đăng ký nhận sự kiện và tạo các trình xử lý để hiển thị thông báo. Nếu trình xử lý cũ chưa được gỡ bỏ hoặc có hai kết nối cùng hoạt động, một sự kiện donate sẽ bị xử lý nhiều lần.

Bản thân việc cập nhật không nhất thiết là nguyên nhân gây lỗi. Nó thường chỉ làm lộ ra lỗi trong logic kết nối. Ví dụ, hàm khởi tạo có thể chạy khi tải trang, rồi chạy lại khi khôi phục kết nối và chạy thêm lần nữa sau khi nhận được thông điệp dịch vụ. Mỗi lần chạy lại sẽ thêm một đăng ký mới cho sự kiện donation.

Kết quả là máy chủ chỉ gửi một đối tượng donate, nhưng trình duyệt lại gọi cùng một hàm hai lần. Đôi khi việc nhân đôi xảy ra ở phía máy chủ: ứng dụng coi kết nối mới là một người nhận riêng biệt và gửi sự kiện cho cả phiên cũ lẫn phiên mới. Vì vậy, trước tiên cần xác định nơi xuất hiện sự lặp lại: ở nguồn, ở trình xử lý hay ở giai đoạn hiển thị.

Cách tìm nơi phát sinh sự trùng lặp

Hãy bắt đầu bằng một bài kiểm tra đơn giản. Mở liên kết của nguồn trình duyệt trong một cửa sổ hoặc tab riêng, chỉ để lại một bản của trang và gửi một sự kiện thử. Nếu cảnh báo chỉ xuất hiện một lần, nguyên nhân nhiều khả năng liên quan đến cấu hình cảnh hoặc đến việc có nhiều bản của nguồn. Nếu nó đã bị nhân đôi ngay trong tab riêng, hãy kiểm tra mã của trang và cơ chế đăng ký.

Nên tách quá trình xử lý donate thành nhiều giai đoạn: nhận sự kiện, kiểm tra sự kiện, đưa cảnh báo vào hàng đợi và hiển thị. Tạm thời ghi lại dấu vết ở từng giai đoạn trong nhật ký hoặc console. Nếu bản ghi về việc nhận xuất hiện hai lần, vấn đề nằm trước lớp hiển thị. Nếu sự kiện chỉ được nhận một lần nhưng trong hàng đợi có hai phần tử, lỗi nằm ở trình xử lý. Nếu hàng đợi chỉ có một phần tử mà trên màn hình có hai cảnh báo, hãy kiểm tra hàm hiển thị và vùng chứa HTML.

Để chẩn đoán, hãy gắn mã định danh của từng sự kiện nếu mã này được truyền trong dữ liệu donate. Ghi lại mã định danh này khi nhận và trước khi hiển thị. Cùng một mã định danh trong hai lần gọi cho thấy một sự kiện đã bị xử lý lặp. Hai mã định danh khác nhau cho thấy có hai lần gửi đến và cần phân tích riêng.

Đừng chỉ kiểm tra số lượng tab. Trong OBS, hai bản có thể xuất hiện sau khi sao chép cảnh, thêm cảnh lồng nhau hoặc thêm lại nguồn trình duyệt với cùng địa chỉ. Đôi khi một nguồn vẫn nằm ở lớp riêng và nguồn thứ hai được thêm lên trên. Nhìn bề ngoài giống như cảnh báo bị nhân đôi, dù sự kiện chỉ đến một lần.

Đăng ký lặp sau khi kết nối lại

Nguyên nhân phổ biến nhất là trình xử lý được thêm vào mỗi lần kết nối nhưng không được gỡ bỏ khi ngắt kết nối. Nói đơn giản, vấn đề diễn ra như sau: hàm gọi socket.on với trình xử lý hiển thị cảnh báo, sau đó kết nối bị ngắt, ứng dụng kết nối lại và lặp lại socket.on. Sau đó, một lượt donate đến sẽ gọi hai hàm. Ở lần kết nối lại tiếp theo, số hàm có thể còn tăng thêm.

Lỗi tương tự cũng gặp với addEventListener thông thường. Nếu hàm khởi tạo được gọi nhiều lần, trình duyệt sẽ thêm nhiều trình lắng nghe cho cùng một sự kiện. Việc kiểm tra cờ “đã khởi tạo” không phải lúc nào cũng giúp ích: khi tải lại toàn bộ trang, các biến sẽ bị đặt lại, còn khi kết nối lại trong cùng một trang, vấn đề vẫn tiếp diễn.

Đăng ký chỉ nên được tạo một lần trong vòng đời của kết nối, và đăng ký cũ phải được gỡ bỏ rõ ràng trước khi tạo đăng ký mới. Với trình xử lý sự kiện, dùng removeEventListener cùng chính tham chiếu hàm đã truyền khi đăng ký. Với các thư viện có socket, thường cần dùng phương thức off, unsubscribe hoặc cách hủy đăng ký tương tự.

Một mẫu tối thiểu cho socket có thể như sau: const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

Điều quan trọng ở đây không phải thư viện cụ thể mà là thứ tự thao tác. Trình xử lý được lưu trong một biến, nên có thể gỡ bỏ bằng chính tham chiếu đó. Trước khi đăng ký mới, đăng ký cũ được xóa, và khi đóng trang hoặc dừng nguồn thì hàm cleanup được thực thi. Nếu mỗi lần chạy lại đều tạo socket mới, trước tiên cần đóng socket cũ rồi mới tạo socket mới. Nếu không, cả hai kết nối có thể tiếp tục nhận cùng một dữ liệu.

Khi kết nối lại, cũng cần đóng kết nối cũ và xóa các bộ hẹn giờ liên quan. Nếu không, socket cũ có thể vẫn tiếp tục nhận dữ liệu trong khi socket mới đã hoạt động. Điều này đặc biệt hay xảy ra khi mã khởi động bộ hẹn giờ kết nối lại mới mà không hủy bộ hẹn giờ trước đó.

Những gì cần kiểm tra trong OBS và nguồn trình duyệt

Nếu cửa sổ riêng chỉ hiển thị cảnh báo một lần, hãy chuyển sang kiểm tra cảnh. Dừng xem trước, tạm thời xóa các lớp thừa và chỉ để lại một nguồn trình duyệt. Sau đó kiểm tra hành vi trên cảnh cần dùng. Cách kiểm tra này nhanh hơn so với việc kiểm tra đồng thời mọi cảnh và bộ lọc.

• Tìm hai nguồn có cùng địa chỉ trang.
• Kiểm tra các bản sao cảnh và cảnh lồng nhau, nơi có thể chứa cùng một overlay.
• Đảm bảo cảnh báo không được hiển thị đồng thời bởi nguồn trình duyệt và một lớp khác có cùng trang.
• Sau khi thay đổi cấu hình, hãy khởi động lại hoàn toàn nguồn chứ không chỉ chuyển cảnh.

Đôi khi trong OBS vẫn còn tab cũ của nguồn trình duyệt sau khi cập nhật URL hoặc tham số. Đóng và thêm lại nguồn giúp kiểm tra giả thuyết, nhưng không thay thế cho việc sửa mã. Nếu sau mỗi lần cập nhật vấn đề lại quay lại, hãy tìm việc đăng ký trình xử lý lặp hoặc kết nối kép.

Cũng cần tính đến độ trễ khi ngắt kết nối. Khi cập nhật, phiên cũ có thể không đóng ngay lập tức. Nếu máy chủ vẫn coi phiên đó đang hoạt động trong vài giây, sự kiện đến trong khoảng thời gian này có thể lọt vào hai phiên. Logic máy chủ đúng chuẩn phải xóa các kết nối không hoạt động và không để lại đăng ký sau khi trang đóng.

Chống gửi lặp cùng một sự kiện

Ngay cả khi nguồn trình duyệt hoạt động đúng, đôi khi một sự kiện vẫn có thể được gửi đến lặp lại. Điều này có thể xảy ra khi khôi phục kết nối, gửi lại thông điệp hoặc xảy ra sự cố giữa lúc nhận sự kiện và lúc xác nhận đã xử lý. Vì vậy, trình xử lý cảnh báo cần có khả năng chống lặp.

Cách tốt nhất là kiểm tra mã định danh duy nhất của lượt donate. Trước khi đưa sự kiện vào hàng đợi, hãy lưu mã định danh của nó vào tập các sự kiện đã xử lý. Nếu mã định danh này đã xuất hiện, cần bỏ qua lần lặp. Chỉ nên lưu danh sách trong thời gian giới hạn để nó không tăng vô hạn.

Không chỉ dùng số tiền, tên người gửi hoặc nội dung thông điệp cho việc này. Hai lượt donate khác nhau có thể có dữ liệu giống nhau. Kiểm tra theo thời gian cũng không đáng tin: nhiều lượt donate khác nhau có thể đến gần như cùng lúc. Nếu không có mã định danh, có thể tạm thời so sánh tổ hợp các trường và thời gian, nhưng đây là phương án dự phòng có nguy cơ gộp nhầm hai sự kiện.

Cơ chế chống trùng lặp phải nằm trước bước hiển thị cảnh báo, không phải bên trong hiệu ứng. Nếu không, lần gọi thứ hai vẫn sẽ thêm phần tử vào trang, phát âm thanh hoặc đưa thêm một bản ghi vào hàng đợi. Cần kiểm soát hàng đợi riêng: một sự kiện chỉ được thêm vào đó một lần, và lần gọi lặp không được kích hoạt một hàng đợi độc lập thứ hai.

Nếu sự kiện được truyền giữa nhiều tab hoặc nhiều thành phần, hãy kiểm tra xem nó có đang bị nhiều bên nhận xử lý cùng lúc hay không. Một kênh thông điệp chung có thể được nối với nhiều trình xử lý. Trong trường hợp đó, cần chỉ để lại một bên tiêu thụ hoặc xác định rõ thành phần nào chịu trách nhiệm hiển thị cảnh báo.

Tại sao xóa bộ nhớ đệm không phải lúc nào cũng giúp

Sau khi cập nhật nguồn trình duyệt, người ta thường khuyên xóa bộ nhớ đệm. Việc này có thể khắc phục tình hình nếu phiên bản cũ của script được tải, nhưng bộ nhớ đệm không xóa các trình xử lý thừa trong trang đang chạy và cũng không đóng bản sao thứ hai của nguồn. Nếu sự trùng lặp lặp lại ổn định sau mỗi lần kết nối lại, nguyên nhân gần như chắc chắn nằm ở logic kết nối hoặc cấu trúc cảnh.

Hãy kiểm tra xem phiên bản mới của tệp có thực sự được tải hay không. Tạm thời thay đổi địa chỉ tài nguyên hoặc dùng cơ chế cập nhật đã có, sau đó khởi động lại nguồn trình duyệt. Tiếp theo, thực hiện lại bài kiểm tra với một cửa sổ và một bản của nguồn. Không nên thêm tham số ngẫu nhiên vào liên kết một cách thường xuyên: việc này có thể tạo ra nhiều biến thể bộ nhớ đệm và làm việc chẩn đoán khó hơn.

Nếu có bộ nhớ đệm trung gian hoặc service worker, nó cũng có thể trả về script cũ. Trong trường hợp đó, hãy so sánh phiên bản của tệp được tải với phiên bản bạn mong đợi. Nhưng ngay cả khi tệp còn cũ, vẫn cần loại bỏ nguyên nhân đăng ký lặp, nếu không vấn đề sẽ xuất hiện lại sau lần cập nhật tiếp theo.

Những gì cần kiểm tra trong mã cảnh báo

Trước tiên, hãy tìm mọi nơi gọi socket.on, addEventListener, các hàm kết nối và việc khởi động hàng đợi. Đôi khi vấn đề không nằm ở một trình xử lý mà ở chỗ hai mô-đun khác nhau cùng lắng nghe sự kiện donation và mỗi bên tự kích hoạt hiển thị riêng.

Sau đó kiểm tra vòng đời của thành phần nếu cảnh báo được hiển thị qua framework. Đăng ký được đặt trong effect hoặc khối tương tự và trả về hàm dọn dẹp. Không được tạo trình xử lý mới mỗi khi trạng thái cập nhật mà không xóa trình xử lý trước đó. Trong JavaScript thông thường, điều quan trọng là lưu tham chiếu đến socket đang hoạt động và trình xử lý hiện tại để có thể đóng chúng đúng cách khi trang dừng.

Kiểm tra các bộ hẹn giờ kết nối lại. Bộ hẹn giờ mới không được chạy chồng lên bộ hẹn giờ cũ. Nếu không, sau vài lần ngắt kết nối sẽ tạo ra các nỗ lực kết nối song song, kéo theo các đăng ký bổ sung. Mỗi bộ hẹn giờ cần được xóa bằng clearTimeout hoặc clearInterval nếu không còn cần thiết.

Riêng phần mã hiển thị cảnh báo cũng cần xem xét. Nó không được đồng thời thêm phần tử vào hàng đợi và gọi ngay hàm hiển thị cho cùng đối tượng đó. Cũng cần kiểm tra xem hiệu ứng có bị chạy lại khi trạng thái của phần tử thay đổi hay không. Nếu trong nhật ký chỉ có một lần nhận và một bản ghi trong hàng đợi, nhưng trên màn hình có hai thông báo, thì cần tìm chính ở đây.

Danh sách kiểm tra chẩn đoán: làm gì theo thứ tự

1. Mở URL của nguồn trình duyệt trong một tab riêng và gửi một lượt donate thử. Ghi nhận xem sự trùng lặp có xuất hiện ngoài OBS hay không.
2. Chỉ để lại một bản của nguồn trong cảnh. Kiểm tra các bản sao cảnh, cảnh lồng nhau và các lớp có thể chứa cùng địa chỉ đó.
3. Thêm nhật ký kèm mã định danh sự kiện ở các giai đoạn nhận, đưa vào hàng đợi và hiển thị. Như vậy sẽ thấy được số lượng đối tượng tăng lên ở đâu.
4. Tìm mọi lệnh gọi socket.on và addEventListener. Kiểm tra xem các trình xử lý cũ có được gỡ bỏ bằng socket.off và removeEventListener với cùng tham chiếu hàm hay không.
5. Kiểm tra việc kết nối lại: socket cũ có được đóng, bộ hẹn giờ cũ có được hủy và có tạo đăng ký mới chồng lên đăng ký trước hay không.
6. Thêm kiểm tra mã định danh duy nhất của lượt donate trước hàng đợi, sau đó khởi động lại hoàn toàn nguồn và lặp lại bài kiểm tra với một sự kiện.

Nếu tab riêng chỉ nhận sự kiện một lần mà OBS hiển thị hai cảnh báo, hãy tìm bản thứ hai của nguồn hoặc sự trùng lặp trong các cảnh. Nếu sự kiện đến hai lần ngay trong tab riêng, hãy kiểm tra đăng ký, kết nối và việc gửi từ máy chủ. Nếu việc nhận và hàng đợi chỉ được ghi nhận một lần nhưng trên màn hình có hai thông báo, vấn đề nằm ở lớp hiển thị.