Increase robustness of "claim developer rewards" (fix reconcilation issue)

[andreibancioiu]

Overview

Regular production flows (i.e. simple transfers of the native token) do not care about this logic change.

See #119.

When the developer rewards are claimed in an intra-shard fashion, the network generates misleading SCRs. In addition to the regular refund SCR, there's a SCR that notarizes the rewards as a misleading balance transfer, from the developer to self. E.g.:

• https://explorer.multiversx.com/transactions?function=ClaimDeveloperRewards&senderShard=0&receiverShard=0

When the developer rewards are claimed in a cross-shard fashion, the network generates misleading SCRs, as well. In addition to the regular refund SCR, there's a SCR that notarizes the rewards as a misleading balance transfer, from the contract to the developer. E.g.:

• https://explorer.multiversx.com/transactions?function=ClaimDeveloperRewards&senderShard=0&receiverShard=1

Either way, correct transaction events with identifier "ClaimDeveloperRewards" are generated.

Proposed changes:

1. Simply ignore all SCRs which seem to hold a developer reward, since they are properly handled by addOperationsGivenTransactionEvents. Unfortunately, the network does not provide a way to easily and properly detect whether a SCR is the result of claiming developer rewards. Thus, in Rosetta, we apply a best-effort (and suboptimal) strategy.
2. Drop operation type DeveloperRewardsAsSmartContractResult (not used).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.90%. Comparing base (d78f87c) to head (0ee159d).
Report is 19 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #133      +/-   ##
==========================================
+ Coverage   61.70%   61.90%   +0.20%     
==========================================
  Files          48       48              
  Lines        3854     3843      -11     
==========================================
+ Hits         2378     2379       +1     
+ Misses       1320     1310      -10     
+ Partials      156      154       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull Request Overview

This PR enhances the handling of developer rewards by ignoring misleading smart contract results (SCRs) and removing an unused operation type.

• Ignore SCRs that appear to carry developer rewards, relying on events instead of legacy logic
• Drop the obsolete DeveloperRewardsAsSmartContractResult operation type
• Update tests, test data, and CI workflow to reflect the new behavior

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
server/services/transactionsTransformer_test.go	Adjusted test name, expectations, and transaction identifiers after logic change
server/services/transactionsTransformer.go	Replaced legacy SCR logic with event-based detection; removed feature gating
server/services/transactionsFeaturesDetector.go	Added documentation on the best-effort detection strategy
server/services/testdata/blocks_with_claim_developer_rewards.json	Updated hashes and added new fields to match detection scenarios
server/services/operations.go	Removed the unused DeveloperRewardsAsSmartContractResult constant
.github/workflows/regularly_check_mainnet.yml	Increased system-test block count from 3000 to 5000 blocks per shard

Comments suppressed due to low confidence (5)

server/services/transactionsTransformer.go:147

• [nitpick] The detailed comment block for handling developer rewards spans many lines and may clutter the function. Consider extracting this explanation into a separate function-level doc or summarizing it inline to improve code readability.

	// (a) When the developer rewards are claimed in an intra-shard fashion, the network generates misleading SCRs.

.github/workflows/regularly_check_mainnet.yml:32

• [nitpick] Updating the block count in each shard run block is repetitive. Consider using YAML anchors or a job matrix to DRY this configuration.

                  python3 ./systemtests/check_with_mesh_cli.py --mode=data --network=mainnet --shard=0 --num-blocks=5000

server/services/transactionsTransformer_test.go:1263

• [nitpick] The test name "recover operations" is quite generic. Consider renaming it to "recover operations using ClaimDeveloperRewards events" to clarify the scenario under test.

	t.Run("recover operations", func(t *testing.T) {

server/services/transactionsTransformer.go:160

• The new logic for ignoring SCRs holding developer rewards is not covered by existing tests. Consider adding a test case for when doesContractResultHoldRewardsOfClaimDeveloperRewards returns false to ensure both branches are verified.

	if transformer.featuresDetector.doesContractResultHoldRewardsOfClaimDeveloperRewards(scr, txsInBlock) {

server/services/transactionsFeaturesDetector.go:22

• [nitpick] The comment mentions a "best-effort (and suboptimal) strategy." Consider clarifying the heuristic or linking to detailed design documentation for future maintainers.

// Unfortunately, the network does not provide a way to easily and properly detect whether a SCR