Sync upstream v11.2.1 (merge conflicts)

[JOY (JOY)]

Upstream Sync - v11.2.1

Auto-merge with upstream v11.2.1 failed. Version/workflow conflicts were auto-resolved,
but the following files have code conflicts that need manual resolution:

docker-compose/envs/common-blockscout.env

To resolve:

1. Check out this branch locally
2. Resolve remaining conflicts
3. Push and merge this PR
4. Then create tag v11.2.1 to trigger Docker build

Upstream release notes

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request introduces comprehensive OpenAPI specifications for the Arbitrum and Advanced Filter endpoints, optimizes real-time event broadcasting in the Notifier by pre-filtering on active subscribers, and adds architectural guidelines for separate API/Indexer modes. However, several critical issues were identified during the review: the new subscriber-filtering logic in Notifier relies on node-local registry lookups which will silently drop real-time updates in distributed deployments, and it publishes un-preloaded token transfers to Absinthe subscriptions, risking N+1 queries or errors. Additionally, the list_methods action in AdvancedFilterController will crash when the optional q parameter is omitted, and globally dropping :batch_numbers in PagingHelper breaks pagination for the public Arbitrum batches endpoint.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Registry.lookup/2 is node-local and only queries the registry of the current Erlang node. In a distributed or split-process deployment (such as running separate api and indexer instances, or multiple clustered api nodes behind a load balancer), clients subscribed to WebSocket topics on other nodes will not be visible to the node running the Notifier. As a result, address_has_subscribers?/1 will return false on publishing nodes, causing real-time updates (coin balances, token balances, transactions, token transfers) to be silently dropped for those clients.\n\nTo fix this, you should avoid filtering broadcasts at the publisher side using local registry lookups, or use a distributed tracking mechanism (like Erlang's :pg groups or Phoenix Tracker) if pre-filtering is absolutely necessary for performance.

[gemini-code-assist]

In the refactored handle_event/1 for :token_transfers, Subscription.publish/3 is called with token_transfers grouped from all_token_transfers instead of all_token_transfers_full. Unlike all_token_transfers_full, all_token_transfers does not have any preloaded associations (such as :token, :transaction, :from_address, :to_address).\n\nWhen Absinthe attempts to resolve fields on these un-preloaded associations for active GraphQL subscription clients, it will either return Ecto.Association.NotLoaded structs (resulting in empty/null fields or errors) or trigger massive N+1 database queries.\n\nTo resolve this, ensure that the token transfers published to Absinthe are fully preloaded.

[gemini-code-assist]

The list_methods/2 action is defined with a single clause matching %{q: query} when is_binary(query). However, the :q parameter is declared as optional (required: false) in the operation :list_methods spec, and the description states: "Without q, returns the default list of popular methods."\n\nIf a client requests this endpoint without the q query parameter, the pattern match will fail, causing the request to crash with a FunctionClauseError.\n\nPlease add a fallback clause to handle the absence of q and return the default list of popular methods.

[gemini-code-assist]

Adding :batch_numbers to the global Map.drop list in delete_parameters_from_next_page_params/1 will strip the batch_numbers query parameter from the generated next_page_params cursor.\n\nWhile this prevents validation errors on the DA-specific endpoints (which don't declare :batch_numbers in their specs), it completely breaks pagination for the public GET /api/v2/arbitrum/batches endpoint. If a client filters batches by batch_numbers and requests the next page, the filter will be lost, and subsequent pages will return all batches instead of the filtered subset.\n\nTo fix this, avoid dropping :batch_numbers globally. Instead, either handle the exclusion specifically for the DA endpoints in the controller, or declare :batch_numbers as an optional parameter on those endpoints.