Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add `take` limits and indexes to the 20+ unbounded `.find()` repository calls

Open
  • Is something wrong?
#239 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
nodejs, typescript
Domain
database

Research direction

Start with the listed .find() sites, beginning with the single-row lookups in src/core/auth/wallet-auth.service.ts and src/blockchain/oracle/services/price-feed.service.ts, and decide per site between findOne, a bounded page, or leaving it alone. Leave user.service.ts:45 as a deliberate batch loader and add a comment saying so. Index changes belong in migrations, with src/common/database/database-index.service.ts used only as a suggestion source. Done means every site is reviewed and recorded, retained filters have migrations, and before/after timings are attached.

Written by the indexing model from the issue text.

Description

advanced help wanted performance

Problem

A scan of src/ found more than 20 repository .find({...}) calls with no take/limit, so they load the entire matching table. Confirmed sites:

  • src/blockchain/oracle/services/nonce-management.service.ts:182
  • src/blockchain/oracle/services/oracle.service.ts:228, 241, 348
  • src/blockchain/oracle/services/price-feed.service.ts:184
  • src/blockchain/oracle/services/submission-batch.service.ts:113, 329, 359, 460
  • src/core/auth/delegation.service.ts:305, 353, 431
  • src/core/auth/enhanced-auth.service.ts:494
  • src/core/auth/wallet-auth.service.ts:290, 391, 472
  • src/core/auth/grantfox-oauth.service.ts:410, 480
  • src/core/auth/oauth.strategy.ts:268
  • src/core/user/user.service.ts:45

Not every one is a defect — user.service.ts:45 uses In(uniqueIds) with a caller-supplied id list and is a deliberate batch loader. But several of the others look like lookups that should return one row, and the oracle and delegation ones operate on tables that grow with activity.

Why it matters

Unbounded reads have cost proportional to table size, forever. They are also a straightforward resource-exhaustion lever: any code path that reaches one of these with a permissive filter reads everything. On the oracle and submission tables this becomes an operational problem as volume grows, because these are the hottest write paths in the system.

Suggested Direction

  1. Triage each call rather than blanket-limiting. For each site, decide whether it wants one row (findOne), a bounded page, or genuinely everything.
    • Sites that look up a single nonce, price, or delegation by a unique key should almost certainly be findOne — that is both faster and clearer about intent.
    • Sites that genuinely need many rows should get an explicit, documented limit and a paginated interface.
  2. Do not cap code that is correct without a cap. A batch loader keyed on a bounded id list (as in user.service.ts:45) should stay as-is; note why in a comment so a future reader does not "fix" it.
  3. Add supporting indexes for any filter you keep, via migrations. src/common/database/database-index.service.ts can generate recommendations, and there is npm run migration:generate — but review anything it suggests rather than applying it wholesale. Note that service builds CREATE INDEX from a template string (database-index.service.ts:114-116); do not follow that pattern.
  4. Add a lint or review heuristic to catch new unbounded reads. An ESLint rule is hard here; a documented convention plus review is more realistic.

Constraints

  • Changing an unbounded read to a paginated one changes API behaviour if it is behind an endpoint. Those need a breaking-change note in CHANGELOG.md and maintainer sign-off.
  • Internal-only reads can be changed freely.
  • Indexes change the schema — use migrations, never synchronize.
  • Benchmark before and after on realistic data volumes; an index that is never used by the query planner costs write throughput for nothing.

Acceptance Criteria

  • Every .find() in src/ either has an explicit bound or a comment justifying its absence.
  • Single-row lookups use findOne.
  • Indexes for retained filters are added via migrations.
  • Behaviour changes on public endpoints are documented and approved.
  • The full list of reviewed sites is recorded in the issue.
  • A before/after query-count or timing measurement is included.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.