Multipage doesn't break pages properly when there's a large number of related items on the main CI; 1000+ pages are created, however most pages have only a few objectsDescriptionDuring Discovery, an unexpectedly high number of multipage ECC queue input entries are created for a single CI, even when the total CI count is low. This behaviour is observed specifically on CIs — such as network switches — that have a very large number of related items (e.g. ports, connections) but relatively few direct CI relationships. Customers may observe: A large volume of ECC queue records with type input and multipage flag set for the same parent CIDiscovery runs taking longer than expected or appearing to stall due to queue backlogNo clear error message — the behavior appears as excessive queue splitting rather than a failure Rootcause: Payload splitting in Discovery is triggered by two independent phases, each governed by separate MID Server properties. The root cause is a combination of low default thresholds for related item counts and payload sizes, which causes excessive splitting when a CI has a high number of related items. Phase 1 — Payload Size / CI Count Threshold Triggered when any of the following thresholds are crossed. Property Default Value Unit Description mid.discovery.max_total_items_size_per_page 3,145,728 B (3 MB) Bytes Max size of all the items per page (it includes CIs + related CI items + relations + references) mid.discovery.max_relation_count_per_page 10,000 Max relations per page Max relations per ECC page mid.discovery.max_ci_count_per_page 500 Max CIs per page Max CIs per ECC page Phase 2 — Related Item Chunk Splitting Triggered when a CI's related item count exceeds the chunk size defined by max_related_count_per_page. Each chunk becomes a separate ECC queue page containing a clone of the parent CI: Property Default Value Unit Description mid.discovery.max_related_count_per_page 100 Max related items per chunk Controls chunk size for related item splitting When both phases interact — for example, a CI with 50,000 related items hitting the default chunk size of 100 — the number of ECC pages created can be extremely large, causing the appearance of a runaway queue even when total CI count is small.Steps to Reproduce Identify a CI with a very large number of related items (>10,000), such as a network switch with a high number of ports or connections, but a low total CI count.Run Discovery against that CI.Navigate to System Logs > ECC Queue and filter for Type = input and the relevant MID Server.Observe that a large number of multipage ECC queue records are created for the same parent CI.Optionally, check MID Server logs for messages referencing mid.discovery.max_related_count_per_page or mid.discovery.max_total_items_size_per_page to confirm which threshold triggered the split.WorkaroundUpdate the following MID Server properties on the specific MID Server(s) used for Discovery. Property values will vary by environment — start with a safe value and tune based on observed behavior. Ensure that the associated MID Server(s) JVM heap size can accommodate the new payload size limits. Property Default Comments mid.discovery.max_related_count_per_page 100 Update if a very large number of related items exist for a CI. mid.discovery.max_total_items_size_per_page 3 MB When payload size is the bottleneck (Example: 10K related items per CI may exceed the 3MB payload limit) mid.discovery.should_minify_pattern_payload false To reduce overall JSON payload size below limit mid.discovery.max_ci_count_per_page 500 Tune if high CI count per page is also a factor mid.discovery.max_relation_count_per_page 10,000 Increase if relation count is the bottleneck Related Problem: PRB1875973