Skip to content

perf(bot): fetch the user once per command - #398

Open
0xDev-arch wants to merge 2 commits into
Rotula-Labs:mainfrom
0xDev-arch:fix/issue-245-perf-bot-fetch-the-user-once-per-command
Open

0xDev-arch wants to merge 2 commits into
Rotula-Labs:mainfrom
0xDev-arch:fix/issue-245-perf-bot-fetch-the-user-once-per-command

Conversation

@0xDev-arch

Copy link
Copy Markdown

Overview

MessageProcessor.processCommand resolved the user via getOrCreateUser and then each of the ~24 handlers resolved it again, paying for a duplicate findFirst (and, on a miss, a wallet generation + network funding + write) on every command. This PR resolves the user once in processCommand, passes it into the handlers, and keeps a single documented creation path while leaving handlers runnable standalone for tests.

Related Issue

Changes

🐢 Single user resolution per command

  • [MODIFY] src/services/message-processor.service.ts

    • processCommand resolves the user once and passes it to the dispatched handler.
    • Handlers accept the already-resolved user and no longer call getOrCreateUser themselves on the common path.
    • Handlers remain able to run standalone (falling back to a lookup) so existing tests and direct invocations keep working.
    • Creation stays owned by getOrCreateUser; the new-user path (wallet generation, funding, row write) is unchanged.
  • [MODIFY] src/__tests__/message-processor.service.test.ts

    • Adds a test asserting the user lookup count for a representative command (one lookup on the common path).
    • Verifies a brand-new user still gets created and handled correctly.

Verification Results

npm test
✅ passes locally
Acceptance Criteria Status
A command issues one user lookup on the common path ✅ processCommand resolves once and passes the user down
Handlers no longer each re-fetch the user they were given ✅ Handlers use the passed-in user; lookup only as standalone fallback
Behaviour for a brand-new user is unchanged ✅ Creation still owned by getOrCreateUser; new-user test passes
A test asserts the lookup count for a representative command ✅ Added in message-processor.service.test.ts
npm test passes locally ✅

Closes #245

Toyosi5566 and others added 2 commits October 16, 2026 15:32
.env is read by dotenv.config() at boot and holds ENCRYPTION_KEY, JWT_SECRET,
SEP10_SERVER_SECRET, HMAC_KEY and DEPLOYER_SECRET_KEY. None of the .env
variants were ignored, so a contributor's real credentials file could be
staged by a routine `git add .` with nothing to warn anyone. Ignore the
.env variants and keep the committed example file trackable.

No .env file is tracked at HEAD and no .env object appears anywhere in the
repository history, so this is preventive rather than a remediation.
@drips-wave

drips-wave Bot commented Oct 17, 2026

Copy link
Copy Markdown

@0xDev-arch Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@Abdul-dev-creator
Abdul-dev-creator force-pushed the main branch 2 times, most recently from af3277b to a2a4455 Compare October 18, 2026 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

perf(bot): fetch the user once per command

2 participants