Add ops-based server filtering for history API

[blazeapps007]

Introduce server-side op-type filtering to /api/query/history (ops param) with batching, cursor advancement, nextFrom/exhausted pagination and Redis fallbacks. Update the client API (apiClient.getHistory) and hooks (use-batch-history, use-rewards-history, use-activity-history) to request server-filtered pages instead of doing client-side filtering; simplify hook logic to consume already-normalized SteemHistoryItem[] and track server-provided nextFrom/exhausted. Add WALLET/ACTIVITY/REWARD op constants (src/lib/steem/history-ops.ts), normalize/cache helpers, and MAX_BATCHES/BATCH_SIZE safeguards. Add devTools sanitizers to redact auth key fields in Redux DevTools and tests for the new behaviors; mark some local filtering helpers as deprecated. Also remove some UI icons from recent-activity and adjust related tests.

[blazeapps007]

The WALLET_OP_TYPES whitelist in src/lib/steem/history-ops.ts is an explicit include list. Only operations in this set are returned; all other operation types are silently filtered out server-side.

Included operation types:

• author_reward — post/comment reward payout
• curation_reward — upvote reward
• comment_benefactor_reward — beneficiary reward
• transfer — send/receive STEEM/SBD
• transfer_to_vesting — power up
• transfer_to_savings — move to savings
• transfer_from_savings — withdraw from savings
• withdraw_vesting — start power down
• fill_vesting_withdraw — periodic power down payout
• claim_reward_balance — claim pending rewards
• delegate_vesting_shares — delegate SP
• return_vesting_delegation — delegation returned
• interest — savings interest payment

Excluded operation types (never returned):

• vote
• comment
• comment_options
• account_witness_vote
• account_witness_proxy
• custom_json
• limit_order_create
• limit_order_cancel
• fill_order
• account_update
• witness_update
• set_withdraw_vesting_route
• Any operation not related to balance movement or reward activity

The server scans raw Steem account history in batches and only accumulates entries where op[0] matches a whitelisted operation type. Non-whitelisted operations are discarded before the response reaches the client.

[ety001]

Architectural Conflict with Existing Lazy-Load Design

The use-batch-history hook on next was designed around a client-controlled, incremental lazy-load loop:

Client loop (max 5 iterations)
  → 1 request to our API server (1 batch = 100 ops from api.steemit.com)
  → Client-side filter
  → Stop once 10 matches accumulated
  → loadMore() fetches next page

This PR changes it to:

Client loop (max 5 iterations)
  → 1 request to our API server
     → Server inner loop (max 20 iterations)
        → Each iteration pulls 100 ops from api.steemit.com
        → Server-side filter
     → Returns filtered results
  → Client accumulates

The Problem: Two Nested Loops

The server-side batching in fetchFiltered introduces an inner loop that the client cannot see or control. In the worst case a single initial page load triggers 5 × 20 = 100 calls to api.steemit.com, completely bypassing the traffic control that the lazy-load design was built to enforce.

Summary

Dimension	Original lazy-load (next branch)	PR 290 behavior
Steem API call control	Client drives batch-by-batch	Server inner loop (up to 20×)
Worst-case API calls on initial load	5	100 (5 × 20)
Filter location	Client	Server
Pagination granularity	100 ops per batch, fine-grained	Server may scan up to 2,000 ops in one shot

Recommendation

If server-side filtering is desired, the server should handle only one batch per request (pull limit ops from Steem, filter, return matches + nextFrom). The client should retain control of the loop and pagination — preserving the incremental load pattern.

The limit parameter should constrain the raw fetch volume from api.steemit.com, not the filtered result count. This keeps the lazy-load contract intact and prevents request amplification.

[blazeapps007]

Addressing these .

[ety001]

Minor: requestedOps Not Deduplicated — Cache Key Pollution

In route.ts:35-37:

const requestedOps: string[] | null = opsParam
  ? opsParam.split(",").map((s) => s.trim()).filter(Boolean)
  : null;

And in route.ts:94:

const opsKey = [...requestedOps].sort().join("+");

There is no deduplication on requestedOps. A caller can send ops=transfer,transfer,transfer,... (repeated N times). Since every element passes the ALLOWED_OPS whitelist check, the request is accepted as valid, but:

1. Cache key pollution — transfer+transfer+transfer and transfer produce different Redis keys, wasting cache space. An attacker could generate arbitrarily many distinct keys.
2. Unnecessary string concatenation — joining thousands of repeated strings before using the key.

Suggested fix — deduplicate right after the whitelist check:

if (requestedOps) {
  const invalid = requestedOps.find((o) => !ALLOWED_OPS.has(o));
  if (invalid) {
    return NextResponse.json({ error: `Unknown op type: ${invalid}` }, { status: 400 });
  }
  requestedOps = [...new Set(requestedOps)]; // deduplicate
}

After dedup, the array has at most 14 elements (the size of WALLET_OP_TYPES), which also eliminates the need for an explicit length cap.

[blazeapps007]

I will Address all these Concerns and Commit

[ety001]

Minor Suggestions

1. Duplicated oldestIndexIn logic in fetchFiltered

The manual loop to find the oldest index in a batch (fetchFiltered in route.ts) reimplements the same logic that existed as oldestIndexIn() in the pre-PR use-batch-history.ts:

// route.ts — inside fetchFiltered, written inline twice
let oldestInBatch: number | undefined;
for (const item of normalized) {
  if (typeof item.index === "number") {
    if (oldestInBatch === undefined || item.index < oldestInBatch)
      oldestInBatch = item.index;
  }
}

This appears twice in fetchFiltered — once during batch iteration and once on the final result. Consider extracting it into a shared utility function (e.g. in normalize-history.ts) so both server and client code can reuse it if needed.

---

2. Missing edge-case tests

Two scenarios are not covered by the current test suite:

• Empty ops param (ops=): filter(Boolean) produces an empty array, which falls through to the non-filtered path. This works correctly but has no test coverage.
• from + ops combined pagination: the existing tests cover from and ops independently, but not the case where a non-default from value is passed alongside ops (i.e. a loadMore request to the filtered endpoint).

Neither is blocking, but would strengthen regression coverage for future changes.

---

3. Content-Type header — no action needed

NextResponse.json() already sets Content-Type: application/json by default. No explicit header needed. Calling this out only to confirm it was checked.

[blazeapps007]

@ety001, you can review now