Apparent caching issue with retrieving azimuth point sponsors #5

New Issue

dosullivan · 2025-10-29T02:30:29Z

dosullivan commented

2025-10-29 02:30:29 +00:00

Earlier today we tried to attest for ~fipfus in the onboarding app, and ran into problems. We turned to the graphQL API at https://azimuth.dev.vdb.to/graphql, and used the following query:

{
  azimuthGetSponsor(
    blockHash: "latest"
    contractAddress: "0x223c067F8CF28ae173EE5CafEa60cA44C335fecB"
    _point: 65370
  ) {
  value
  }
}

It returned:

{
  "data": {
    "azimuthGetSponsor": {
      "value": "0"
    }
  }
}

Every query result appears to be cached in Postgres, keyed by blockHash, contractAddress, _point.

In Azimuth, apparently before an Azimuth point is "activated" the sponsor is 0, so the watcher fetched 0 from the chain and cached it under the key blockHash = "latest".

We later activated the point, and the sponsor value on chain then was 90 (the galaxy ~fus). however, the graphQL API still returned 0 when querying with blockHash: latest. However, if I just passed a block hash for the most recently validated block I saw on etherscan, it returned 90:

{
  azimuthGetSponsor(
    blockHash: "0xc9581c9c6b7f8c8535907d6b68b835c39293bae9d9d9f067d370da24007e881f"
    contractAddress: "0x223c067F8CF28ae173EE5CafEa60cA44C335fecB"
    _point: 65370
  ) {
  value
  }
}

{
  "data": {
    "azimuthGetSponsor": {
      "value": "90"
    }
  }
}

Per Rick's analysis, perhaps this is a bug actually in the onboarding app, like maybe it should use an actual block hash instead of latest. But just filing for visibility.

Earlier today we tried to attest for ~fipfus in the onboarding app, and ran into problems. We turned to the graphQL API at https://azimuth.dev.vdb.to/graphql, and used the following query: ``` { azimuthGetSponsor( blockHash: "latest" contractAddress: "0x223c067F8CF28ae173EE5CafEa60cA44C335fecB" _point: 65370 ) { value } } ``` It returned: ``` { "data": { "azimuthGetSponsor": { "value": "0" } } } ``` Every query result appears to be cached in Postgres, keyed by blockHash, contractAddress, _point. In Azimuth, apparently before an Azimuth point is "activated" the sponsor is 0, so the watcher fetched 0 from the chain and cached it under the key `blockHash = "latest"`. We later activated the point, and the sponsor value on chain then was 90 (the galaxy ~fus). however, the graphQL API still returned 0 when querying with `blockHash: latest`. However, if I just passed a block hash for the most recently validated block I saw on etherscan, it returned 90: ``` { azimuthGetSponsor( blockHash: "0xc9581c9c6b7f8c8535907d6b68b835c39293bae9d9d9f067d370da24007e881f" contractAddress: "0x223c067F8CF28ae173EE5CafEa60cA44C335fecB" _point: 65370 ) { value } } ``` ``` { "data": { "azimuthGetSponsor": { "value": "90" } } } ``` Per Rick's analysis, perhaps this is a bug actually in the onboarding app, like maybe it should use an actual block hash instead of latest. But just filing for visibility.

zramsay commented

2025-11-19 16:28:36 +00:00

this fix was addressed in the onboarding app

zramsay closed this issue

2025-11-19 16:28:38 +00:00

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: LaconicNetwork/azimuth-watcher-ts#5