fix(algo): apply tg_wcc print_limit to the component maps

[eastagiletracker]

This PR proposes applying tg_wcc's print_limit to the per-component maps it prints, so a run on a graph with many components stays within the result size limit (Fixes #127). We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/279. You can sign in with your GitHub ID to claim ownership of the project.

What is wrong today

print_limit bounds only the printed vertex set. @@comp_sizes_map holds one entry per connected component and @@comp_group_by_size_map holds every component id grouped by size, and both are printed in full no matter what print_limit is set to. On a large sparse graph the component count is the thing that grows, so the part of the response print_limit was meant to cap is exactly the part that stays uncapped.

Reproduction at current HEAD

On tg_4.4.0_dev (c8ca472), with a stock engine and 20 isolated V20 vertices — so 20 single-vertex components — tg_wcc was installed unmodified and run with print_limit=5:

docker run -d --name tg -p 9000:9000 tigergraph/community:4.2.4
# ... create graph_algorithms_testing(V20, Empty), upsert 20 V20 vertices, INSTALL QUERY tg_wcc
curl -s 'http://127.0.0.1:9000/query/graph_algorithms_testing/tg_wcc?v_type_set=V20&e_type_set=Empty&print_limit=5'

The vertex list honors the limit and the two maps ignore it:

Start printed:       5     <- honors print_limit
sizes entries:      20     <- one per component, ignores print_limit
group_by_size ids:  20     <- ignores print_limit

On that same 20-component run the two maps are most of the payload, and on a 50-component version of it they were 1228 of the 1719 response bytes at print_limit=5 against 378 bytes for the capped vertex list. The maps grow with the component count while the capped part does not.

The change

The FOREACH that builds the grouped map now stops after print_limit components and fills a @@print_comp_sizes_map alongside it, which is what gets printed as sizes. print_limit < 0 keeps the documented "print everything" path, so existing callers are unaffected. The parameter comments were updated to say the limit covers components as well as vertices. Nothing in the traversal, the result_attribute write path or the file_path CSV path is touched.

Verification

Same engine, same graphs, before and after. With print_limit=-1 the full response is byte-identical to the pre-change run (10847 bytes on the 60-component graph), and every vertex's component assignment is unchanged at every limit — the capped maps are strict subsets of the uncapped ones, so no value is altered, only omitted. Edge values behave: print_limit of 0, 1, 59, 60 and 1000 against 60 components return 0, 1, 59, 60 and 60 entries, and print_results=false still prints nothing.

tests/test/test_community.py gains test_wcc_print_limit over the Empty graph, where every vertex is its own component. Against the unmodified query the three limits fail and the -1 case passes:

FAILED test/test_community.py::TestCommunity::test_wcc_print_limit[0] - assert 20 <= 0
FAILED test/test_community.py::TestCommunity::test_wcc_print_limit[1] - assert 20 <= 1
FAILED test/test_community.py::TestCommunity::test_wcc_print_limit[5] - assert 20 <= 5
3 failed, 1 passed

With the change applied, 4 passed. Running the whole of test_community.py before and after leaves the same 15 test_lcc* failures either way — those look for data/baseline/graph_algorithms_baselines/..., which is not in the repo — so this adds no new failures.

How this was managed

This work was tracked as tg_wcc query parameter output_limit not effective on a board at https://eastagiletracker.com/projects/279 that was imported from this repository's own issues and pull requests — 185 of them — and used to manage the change.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

---

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com