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:
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:
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
It returned:
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: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.
this fix was addressed in the onboarding app