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

Extract domain logic from `src/blockchain/oracle/services/submitter.service.ts` (620 lines)

Open
#203 0 comments 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

Research direction

Start with the retry loop in src/blockchain/oracle/services/submitter.service.ts (around lines 235-241) and the matching loop with the payloadRepository.findOne check in submission-batch.service.ts (around lines 216-219). Check src/common/utils/ for an existing helper and read payload-signing.service.spec.ts for the test style. Done when a shared retry helper is used, the idempotency check runs once per payload, and a spec shows a fail-then-succeed submission produces exactly one transaction, with npx tsc --noEmit and npm test passing.

Written by the indexing model from the issue text.

Description

advanced refactor

Problem

src/blockchain/oracle/services/submitter.service.ts is 620 lines — the second-largest file in the repository. It handles gas estimation, submission retry, and payload lifecycle in one service. The retry loop at lines 235-241 shows several concerns interleaved:

for (let attempt = 1; attempt <= this.maxRetries + 1; attempt++) {
  const gasEstimate = await this.estimateGas(payload);
  const gasLimit = BigInt(
    Math.ceil(Number(gasEstimate) * this.gasLimitMultiplier),
  );
  ...
}

Gas estimation, retry/backoff policy, and transaction submission are three distinct concerns being driven from one loop. There is a related submission-batch.service.ts (656 lines) with a structurally similar retry loop at line 216, so the retry policy is duplicated across both files.

Why it matters

This is the on-chain submission path — the README's "critical outcomes are signed and auditable" boundary. Two files implementing retry policy independently will drift, and a drift here means duplicate or dropped on-chain submissions. The duplicated idempotency check at submission-batch.service.ts:219 (payloadRepository.findOne({ where: { id: payloadId } })) runs on every retry attempt, so the retry cost includes a database round-trip per attempt that the batch service may already have done.

Suggested Direction

  1. Extract a shared retry utility. Both loops implement the same shape. Put a small retry(fn, { maxAttempts, backoff, shouldRetry }) helper somewhere shared — check src/common/utils/ for where similar utilities already live.
  2. Separate the concerns in submitter.service.ts:
    • gas-estimation.service.ts — wraps estimateGas and the multiplier math
    • submission-retry.service.ts — the retry/backoff policy
    • keep SubmitterService as the orchestrator
  3. Move the idempotency check out of the retry loop. Fetch the payload once before the loop instead of re-querying per attempt (this also has a performance benefit — see the retry-loop performance issue).
  4. Add colocated specs. There is src/blockchain/oracle/services/payload-signing.service.spec.ts already, so signing is covered — submission is not.

Constraints

  • Idempotency is critical. A retry must never produce a duplicate on-chain transaction. Preserve or strengthen the idempotency guarantee; do not remove the check to save a query.
  • Retry counts, backoff intervals, and the gas multiplier are operational tuning parameters — keep them externally configurable.
  • submission-batch.service.ts should get the same treatment, but consider doing it in a follow-up PR so each is reviewable.

Acceptance Criteria

  • A shared retry helper exists and is used by submitter.service.ts.
  • submitter.service.ts no longer exceeds ~350 lines.
  • The idempotency check is not executed redundantly per retry attempt.
  • A test asserts a failing-then-succeeding submission produces exactly one on-chain transaction.
  • npx tsc --noEmit and npm test pass.
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.