Denozordec
9fa6269174
Implement reliable agent apply, telemetry v2, analytics retention, guarded rollouts, enrollment, labels and webhooks. Improve ReUI frontend data safety and bounded list loading, and add Docker smoke, recovery and resource checks. Document local verification and pending native acceptance.
3.1 KiB
Bounded list import response
POST /api/v1/lists/:id/entries?return=summary opts into a bounded response:
{"count":100000,"content_hash":"sha256:...","changed":true}
count is the total stored effective CIDR count after publication. content_hash is the stored content hash; changed records whether the root list's effective memberships changed. The response is derived from a SQL count and hash projection and does not serialize stored rows, source config or full list detail.
The opt-in path accepts a fully duplicate valid import as a successful no-op with changed:false, preserving agent generations. Mixed valid/invalid input still rejects the entire request before publication. With no query parameter the existing full-detail success response and duplicate-import error behavior remain unchanged. The existing 100000-entry and 8 MiB import bounds apply to both modes.
The frontend import/delete mutations use summary responses and invalidate list queries. DELETE /lists/:id/entries?return=summary returns the same summary after atomic deletion. Default delete responses remain full details.
GET /lists/:id?view=page&limit=100&offset=0 opts into SQL pagination (limit 1–200, offset 0–10000000). Without query parameters the legacy full detail remains available. Invalid paging/filter parameters reject the request instead of falling back to the full response. Paged responses contain metadata, bounded items and preview entries, total stored entry_count, filtered logical-item total, limit and offset. config_json is {}; raw source config is not returned. Each item contains the true resolved_count, at most three resolved_cidrs previews and resolved_truncated.
Optional q searches value/name and kind. filters is JSON for at most ten filters: {field:'value'|'kind',operator,values:string[]}. Operators match the frontend's is, is_not, is_any_of, is_not_any_of, contains, not_contains, starts_with, ends_with, empty and not_empty. Filters combine with AND, values with OR. Filtering occurs over the entire list before pagination; nested-list value text includes its child name and ID. The deterministic SQLite evofw_lower function preserves JavaScript Unicode case folding for names.
Manual source items are projected through SQLite JSON1 and external CIDRs through ip_list_entries; full rows/config/resolution arrays are not materialized in JavaScript before slicing. GET /lists?view=summary also excludes source config from the metadata catalog query. Defaults for both endpoints preserve legacy behavior.
Observed Windows/in-memory endpoint test: 100000 unique IPv4 inputs returned 120 response bytes in approximately 1363 ms. A 200-item page from that list returned 31048 bytes; an exact filter for the 100000th item returned 524 bytes. These are local samples, not production or two-CPU capacity claims. Tests also cover full duplicate no-op without generation bumps, invalid mixed input preserving count/hash/revision, default legacy detail shape, bad paging/filter parameters, external-prefix pagination, bounded nested-list resolution previews and Unicode child-name filtering.