giới hạn alarm 32kb

  Tôi sẽ xem file CSV và code widget trong zip trước.

Không phải do khoảng trắng. Code widget đọc file CSV của bạn đúng, đủ 1184 tag.

Đã kiểm tra:

• File CSV hợp lệ: UTF-8 có BOM, xuống dòng CRLF, header Tag, mỗi dòng 1 tag, không có dấu , ; " nào trong tên tag.
• 43 dòng có khoảng trắng thừa ở cuối (ví dụ ...GCB drawer ). Hàm .trim() trong code đã cắt hết, và tên tag có khoảng trắng ở giữa vẫn giữ nguyên. BOM và dòng header Tag cũng được bỏ đúng.
• Tôi chạy thử đúng hàm csvRows + splitCsv của widget.js trên file này: ra 1184 tag, không trùng.

Nên lỗi nằm ở bước sau parse. Widget gọi editTags(s, 'add', rows), rồi s.ctx.editList('tags','add',list) gửi cả 1184 tag (~47.000 ký tự) trong một lần lên server. Mã phía server (Blazor, editList) không nằm trong zip nên tôi không kiểm chứng được. Các nghi vấn, xếp theo khả năng:

1. Server giới hạn kích thước hoặc từ chối request lớn. Tag lưu trong prop tags dạng text, nên một lần ghi 47KB rất dễ vượt giới hạn. Khi đó editList trả null và widget chỉ hiện dòng nhỏ “Không lưu được lên hệ thống” ở .pb-tm. Thông báo này nằm ngay dưới hàng nút, rất dễ bỏ sót.
2. Thiếu quyền điều khiển. Nếu canWrite = false, nút Nhập CSV và nút + bị disable. Ảnh của bạn thì nút trông vẫn bình thường.
3. Server chưa cập nhật. Nếu không có editList, tag chỉ lưu tạm vào localStorage của trình duyệt. Quota localStorage thường đủ cho 47KB, nên khả năng này thấp.

Ảnh của bạn cũng cho thấy Tags (1), tức chưa tag nào được thêm.

Cách xác định nhanh:

• Nhấn F12, mở tab Console và Network, bấm Nhập CSV lại, rồi xem request lên server trả mã gì (413, 400, 500...). Gửi mình mã lỗi hoặc dòng chữ hiện dưới hàng nút.
• Thử file CSV nhỏ (5 dòng đầu). Nếu nhập được thì chắc chắn là lỗi giới hạn kích thước.

Cách sửa: nên tách danh sách thành các lô khoảng 100 tag mỗi lần gửi. Việc này sửa ngay trong widget.js, ở handler .pb-tf (dòng ~191), không cần đụng server. Ngoài ra nên hiển thị lỗi rõ hơn và báo tiến trình kiểu “Đã thêm 300/1184...”. Bạn muốn mình sửa và gửi lại bản zip v2.2.2 không?ôi đã tìm ra nguyên nhân trong code gốc. Khoảng trắng không liên quan, lỗi nằm ở giới hạn kích thước message của Blazor Server.

Chuỗi xử lý:

1. widget.js parse đúng 1184 tag, rồi gọi ctx.editList('tags','add', list).
2. plug.js:68 gọi invokeMethodAsync('EditList', ..., items) qua SignalR, gửi cả 1184 tag trong một message (~47 KB nội dung, cộng thêm phần JSON bao quanh).
3. Program.cs:47 chỉ có AddRazorComponents().AddInteractiveServerComponents(), không cấu hình HubOptions. Blazor Server mặc định MaximumReceiveMessageSize = 32 KB, nên server từ chối message này.
4. plug.js có .catch(() => null) nên lỗi bị nuốt, widget chỉ hiện dòng “Không lưu được lên hệ thống” rất nhỏ. Tag không được thêm, Tags (1) giữ nguyên, đúng như ảnh của bạn.

Phần EditList ở server (PluginBox.razor) thì ổn: trim từng tag, bỏ trùng, giới hạn 50.000 tag. Phần này không liên quan đến lỗi.

Cách sửa (nên làm cả hai):

1. Server: nâng giới hạn, sửa Program.cs dòng 47:

csharp

b.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddHubOptions(o => o.MaximumReceiveMessageSize = 8 * 1024 * 1024);

Với mục tiêu 100k tag thì 8 MB là đủ (100k tag ≈ 4 MB).

2. Widget: chia lô khi nhập CSV, để chạy được cả trên server chưa nâng giới hạn. Ví dụ 300 tag mỗi lô, gửi tuần tự, hiện tiến trình “Đã thêm 300/1184...”. Trong handler .pb-tf của widget.js (dòng ~189).

Một điểm nên kiểm tra thêm: 43 dòng trong CSV có khoảng trắng thừa ở cuối, ví dụ ...GCB drawer . Widget luôn trim() tag khi thêm và khi lọc alarm. Nếu tên tag thật trong project cũng có khoảng trắng cuối, alarm của các tag đó sẽ không khớp. Bạn nên xem tên tag thật trong project, hoặc chỉnh lại file CSV nguồn.

Bạn muốn mình sửa luôn hai chỗ trên và gửi lại widget.js (v2.2.2) cùng bản vá Program.cs không?Tùy bạn có chia lô ở widget hay không:

Cách làm	Giới hạn nên đặt
Có chia lô (300 tag mỗi lần, ~12-15 KB/lần)	128 KB là thừa, 256 KB cho thoải mái
Không chia lô (gửi cả file một lần)	8 MB (8 × 1024 × 1024)

Cách tính: file của bạn có 1184 tag ≈ 47 KB, trung bình ~40 byte/tag. Với mục tiêu 100k tag thì 100.000 × 40 ≈ 4 MB. Server cho phép tối đa 50.000 tag trong EditList, tức khoảng 2-4 MB. Đặt 8 MB là gấp đôi mức xấu nhất, nên đủ chỗ.

Khuyến nghị: chia lô ở widget và đặt giới hạn server là 1 MB:

csharp

.AddHubOptions(o => o.MaximumReceiveMessageSize = 1024 * 1024);

Nhập 100k tag sẽ thành ~330 lô, mỗi lô một lần E.Save(). Việc này chậm hơn một chút nhưng ổn định. Nếu muốn nhập một lần cho nhanh thì dùng 8 MB, không cần chia lô.

Đừng đặt quá lớn (ví dụ 100 MB). Giới hạn này chặn một client gửi message khổng lồ làm tốn RAM server, và nó áp dụng cho mọi message SignalR của app, không riêng widget này. 1-8 MB là vừa đủ cho SCADA.

Bạn chọn cách nào để mình viết code luôn?

Mình đã sửa xong cả hai chỗ, giới hạn server đặt 256 KB như bạn muốn.

1. Program.cs: dòng 47 giờ là:

csharp

b.Services.AddRazorComponents().AddInteractiveServerComponents()
    .AddHubOptions(o => o.MaximumReceiveMessageSize = 256 * 1024);

Mình chỉ đổi đúng dòng này, các phần khác giữ nguyên. Bạn cần build lại và restart server.

2. alarm_tags_v2_2_2.zip (widget.js / widget.css / widget.json, phiên bản 2.2.2):

• Nhập CSV chia lô 300 tag mỗi lần (~14 KB), thấp hơn nhiều so với 256 KB.
• Có tiến trình “Đang nhập CSV... 600/1184”.
• Nếu lỗi giữa chừng, widget báo “chỉ nhập được X/Y tag”. Bấm nhập lại thì các tag đã có tự bị bỏ qua và tiếp tục phần còn lại.
• Danh sách ≤ 300 tag hoặc server chưa có editList vẫn đi đường cũ như trước.

Mình đã chạy thử trên file thật của bạn, kết quả là 4 lần gọi server (300 + 300 + 300 + 284 tag), mỗi lần tối đa ~13,8 KB, thông báo “Đã thêm 1184 tag từ CSV”. Mình chưa build được Program.cs vì không có .NET SDK ở đây. Dòng AddHubOptions đó chuẩn cho .NET 8 trở lên, nếu build báo lỗi bạn gửi lại thông báo để mình xem.

Bạn nhớ kiểm tra thêm vụ 43 dòng có khoảng trắng thừa ở cuối tên tag so với tên tag thật trong project, vì widget luôn trim() tên tag.

Nội dung chính