Detects and triages unbounded AEM queries that cause out-of-memory failures.
npx skills add https://github.com/aemgdc/aemdev --skill unbounded-query-aemgdc
Please help me install this Agent Skill. Skill: unbounded-query Source: https://github.com/aemgdc/aemdev/tree/main/.agents/skills/unbounded-query Command: npx skills add https://github.com/aemgdc/aemdev --skill unbounded-query-aemgdc
p.limit=-1 or setLimit(-1)) load entire result sets into heap, and when iterated in a loop they cause out-of-memory outages — the top OOM cause in AEM Cloud Service. This Skill finds those queries and fixes them safely without silently dropping rows. ## Core Features & Use Cases - Precise detection: Flags the two explicit unbounded markers — QueryBuilder p.limit=-1 predicate entries and JCR setLimit(-1) calls — including same-file constant references. - Consumption-based triage: Classifies each finding by how results are consumed (single-result, bounded list, iterate-all) and applies the safe fix: bound to 1, bound to N, or wrap in an offset paging loop. - Safe escalation: Request-path iterate-all queries are flagged as needs-pagination for human review rather than silently capped, preventing silent data truncation bugs. - Use Case: A scan flags p.limit=-1 in your search component after an OOM incident. The Skill reads the consuming method, bounds a single-result lookup to 1, and escalates a cross-method iterate-all query with a pagination recommendation. ## Quick Start Ask the assistant to scan my AEM project for unbounded queries and fix or flag each one based on how the results are consumed.High-intent search queries and answers about installing and using this skill.
First identify how the result is consumed. Single-result lookups can be bounded to 1, top-N lists to their display size, and iterate-all cases need offset paging loops. Request-path queries that read all rows should be escalated for human pagination rather than silently capped.
The p.limit=-1 predicate tells QueryBuilder to return every matching row, loading the entire result set into heap. When those results are traversed in a loop, the heap fills and the instance can OOM, making it a leading cause of AEM Cloud Service memory outages.
Capping is not behavior-neutral: if the real result exceeds the cap, rows are silently dropped, causing wrong counts and truncated lists. Only cap where the caller provably reads a bounded subset; otherwise add offset paging or escalate for a human decision.
Yes, the detector flags both explicit markers: QueryBuilder predicate entries put("p.limit", "-1") and JCR query.setLimit(-1) calls, including values passed through same-file final constants. Bounded queries and -1 values on other keys are not flagged.
Findings are skipped with recorded reasons when the query runs on the request path consuming all rows (needs-pagination), when it is an off-request batch job needing the full set, or when it is test code under src/test. Skips are surfaced in the report, never silently dropped.
anorthamDetect N+1 query patterns in loops across multiple languages with file locations and fixes.
jiten-singh-shahiPaginate large SOQL result sets using Database.Cursor and PaginationCursor APIs.
hoangnh2412Interpret .NET runtime GC and memory metrics to diagnose memory pressure and leaks.
JKKN-InstitutionsBuild server-side data tables for Next.js apps with Supabase.