Studio UI shows indexing timeout error, but public UI shows no issues

[rickstaa]

Description

When viewing the subgraph in Subgraph Studio as the owner, the deployment is shown in a Failed Syncing state due to a non-deterministic indexing timeout. This was first observed on 2026-01-03 at 22:36:16, failing at block 416127553, despite no subgraph code, manifest, or configuration changes for ~2 years.

At the same time, the public Graph Explorer for the same deployment ID (QmcQY5m381fPQUS6cEFY4VFZadtarYXNfRbEWJ7G7gbq7T) reports 100% indexing progress, shows no errors, and continues to serve queries normally.

This indicates the issue is not a general subgraph failure, but instead appears to be specific to the indexer backing Subgraph Studio (likely the Studio / Upgrade Indexer) encountering a long-standing or newly triggered indexing edge case, resulting in a mismatch between Studio and network-visible indexing state.

If the Studio-reported failure is authoritative for deployments or future indexing actions, this could block operational workflows despite the subgraph remaining queryable on the network.

Observed Behavior

• Subgraph Studio UI

  • Status: Failed Syncing
  • Indexing halts at block 416127553
  • Repeated retries with increasing backoff
  • Error reported as non-deterministic

• Public Graph Explorer (same deployment ID)

  • Status: Indexing / 100% synced
  • Head block advances normally
  • Queries return expected results

• Error reported by Studio

  Subgraph failed with non-deterministic error: failed to process trigger:
  block #416127553 (0xef71…b65d), transaction
  26027f4b0e28c8390e737a902ce873f5686e502c2bae79f40871d9ea46e3d3a8:
  
  Handler 'newRound' hit the timeout of '1200' seconds:
  Failed to call 'asc_type_id' with 'ArrayBuffer'
  wasm trap: interrupt
  retry_delay_s: 3784, attempt: 68
  

Expected Behavior

• Indexing state should be consistently healthy across Studio and network views

Impact

• No immediate production impact
  • Public queries remain healthy and up-to-date.
• Operational risk
  • Studio reporting a failed deployment may:
    • Block future deployments
    • Prevent upgrades or redeploys
    • Cause confusion about actual subgraph health
• Maintenance risk
  • Indicates a potential long-tail indexing edge case triggered only under specific runtime or data conditions.

Attachments

See screenshots

Notes / Hypothesis

• The subgraph has been stable for ~2 years with no changes.
• The failure appears non-deterministic and indexer-specific.
• Likely explanation:
  • The Studio/Upgrade Indexer is encountering a timeout or resource-related edge case while processing newRound, while other indexers have already indexed or can process this block successfully.
• This suggests a need to clarify:
  • Whether Studio reflects a single indexer’s state

Next steps

@mehrdadmms, since I’m out of office, I recommend the following next steps:

• Have Elliot merge chore: allow subgraph endpoint override via env var explorer#468 so the explorer team can fall back to the previous deployment if needed.
• Ask BuildersDAO to validate my hypothesis and confirm that it’s safe to release a new version.
• If confirmed safe, coordinate with @yondonfu to deploy the new version by pushing a new tag.
• BuildersDAO can perform a more comprehensive audit later, which should also cover this edge case and allow it to be patched if necessary.

[rickstaa]

@jmulq thanks for your detailed reponse in DM. The bug has resolved itself now on the Studio UI. So I think our hypothesis that this is an error at an indexer attached to the studio UI is valid. We migh want to investigate further why this occured in the audit.