### Summary
The output of `GET /api/v1/vaas` was not being correctly sorted. This pull request changes the behavior so that the output will be sorted by the `timestamp` field.
Additionally, duplicated code was removed in the VAA code that handles queries.
Also, there was an unused query parameter `sortBy` which was being exposed but not used. Hence it was removed.
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/233
### Summary
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/254
For all chains except Solana, the data in `globalTransactions.sourceTx` was somewhat duplicated, since we already had that data in the `vaas` collection.
This pull request changes the `tx-tracker` service so that no redundant data will be written, and also changes the API to look up the data from the `vaas` collection instead.
The responses from the endpoint `/api/v1/global-tx` will no longer contain the field `originTx.from`.
### Summary
This pull request adds the `GET /api/v1/scorecards` endpoint, which is required by the wormscan frontend.
Most of the fields that this endpoint should return are being omitted because the data is not currently available on the backend. Those fields will be added iteratively as the data becomes available.
The current format of the response is:
```json
{
"total_tx_count": "1300200",
"24h_tx_count": "4200"
}
```
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/221
## Deployment details
In order to populate the `"total_tx_count"` metric, a task is needed in influxdb:
```
$ cat total-vaa-count.flux
option task = {
name: "Total number of emitted VAAs",
every: 1m
}
from(bucket: "wormhole-explorer")
|> range(start: 2018-01-01T00:00:00Z)
|> filter(fn: (r) => r._measurement == "vaa_count")
|> group(columns: ["_measurement"])
|> set(key: "_measurement", value: "total_vaa_count")
|> count()
|> map(fn: (r) => ({r with _time: now()}))
|> map(fn: (r) => ({r with _field: "total_vaa_count"}))
|> to(bucket: "wormhole-explorer", org: "xlabs")
```
### Summary
This pull request adds the functionality to search for VAAs using Solana tx hashes, e.g.:
`GET /api/v1/vaas?txHash=2qnNNBQQQ152sGkQ1Rnq2Kdr48LvdN4oXwnTWyEmJqYYWFusLWxbwhpGS5KTXH1bKKx9gg9BLZMKd3g1cXiy7QMz`.
Also, the VAA objects returned by the API now have a new field `nativeTxHash`, which contains the tx hash that generated the VAA in the native format of the emitter chain.
Tracking issues: https://github.com/wormhole-foundation/wormhole-explorer/issues/212, https://github.com/wormhole-foundation/wormhole-explorer/issues/214
### Testing guidelines
Endpoints affected:
* `GET /api/v1/vaas` now supports Solana tx hashes by using the `?txHash=` query parameter. This search is limited to VAAs created by the portal token bridge.
* Some VAAs returned by the API should have a new field `nativeTxHash`. All VAAs related to the portal token bridge should have this field set.
* An internal refactoring affected pretty much all routes under `GET /api/v1/vaas*`, which should be re-tested.
* In the response of `/api/v1/global-tx/`, the field `originTx.signer` has been renamed to `originTx.from`
### Summary
Several endpoints related to VAAs and observations returned `null` when no results were found.
This commit changes the behavior to return `[]` instead, which is more ergonomic for users.
Endpoints affected:
- `GET /api/v1/observations/:chain`
- `GET /api/v1/observations/:chain/:emitter`
- `GET /api/v1/observations/:chain/:emitter/:sequence`
- `GET /api/v1/observations/:chain/:emitter/:sequence/:signer/:hash`
- `GET /api/v1/vaas/{chain_id}`
- `GET /api/v1/vaas/{chain_id}/{emitter}`
- `GET /api/v1/vaas/{chain_id}/{emitter}/{seq}`
Fix governor endpoints
A few governor endpoints were handling addresses incorrectly,
which resulted in errors.
* `GET /api/v1/governor/config/{governor_address}`
* `GET /api/v1/governor/status/{governor_address}`
This commit fixes the issue and adds doc comments to prevent the
same caveat from happening again in the future.
### Summary
This PR enables passing emitter addresses in Solana format when the `chainId` parameter is set to 1. If `chainId` is set to a different value, the API will expect a regular Wormhole address.
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/189
### Endpoints affected
- `GET /api/v1/global-tx/{chain_id}/{emitter}/{seq}`
- `GET /api/v1/observations/:chain/:emitter`
- `GET /api/v1/observations/:chain/:emitter/:sequence`
- `GET /api/v1/observations/:chain/:emitter/:sequence/:signer/:hash`
- `GET /api/v1/vaas/{chain_id}/{emitter}`
- `GET /api/v1/vaas/{chain_id}/{emitter}/{seq}`
### Example
These two calls should be equivalent:
- `GET /api/v1/vaas/1/ec7372995d5cc8732397fb0ad35c0121e0eaa90d26f828a534cab54391b3a4f5` (address in Wormhole format)
- `GET /api/v1/vaas/1/Gv1KWf8DT1jKv5pKBmGaTmVszqa56Xn8YGx2Pg7i7qAk` (the same address, in Solana format)
* init contract-watcher
* Add processor and blockain watchers
* Add pagination and save last blocknumber procesed by chain
* Add processing by blocks
* Add contract-watcher deploy manifest
* Add endpoint to get globalTransactions by Id
* Add originTX to get globalTransactionById endpoint
* Add wait time for new blocks
* Add initial block for evm watcher
* Add rate limit for evm watcher
* Handle testnet environment and small fixes
* Update wormhole dependencies
* Fix api documentation for swagger
---------
Co-authored-by: Agustin Pazos <agpazos85@gmail.com>
### Summary
Context: https://github.com/wormhole-foundation/wormhole-explorer/issues/154
This PR modifies all endpoints that receive an emitter/guardian address to accept a wider range of formats.
After this pull request, all of these are equivalent:
* `0x000000000000000000000000f890982f9310df57d00f659cf4fd87e65aded8d7`
* `000000000000000000000000f890982f9310df57d00f659cf4fd87e65aded8d7`
* `0xf890982f9310df57d00f659cf4fd87e65aded8d7`
* `f890982f9310df57d00f659cf4fd87e65aded8d7`
### Testing plan
* Added unit tests for the parsing code.
* Tested manually a few of the affected endpoints.
### Summary
* Swagger: remove `sortOrder` query parameter from several endpoints in which it didn't make sense.
* Swagger: remove query params `page` and `pageSize` from endpoints that return a single object.
* Sort the output of `GET /api/v1/governor/config` by ascending id.
* Refactor: remove duplicated code, format code for readability.
The API's swagger documentation exposes a route
`GET /api/v1/governor/max_available/:chain`,
but instead it should be
`GET /api/v1/governor/notional/max_available/:chain`.
### Summary
Changes to `GET /api/v1/governor/limit`:
* Fix the behavior of the parameters `page` and `pageSize` (which previously were being ignored).
* When no results are found, return an HTTP status code of 200 and set the response to an empty array.
* Remove the `sortOrder` query parameter.
The rationale for removing the `sortOrder` parameter is that sorting chains by ascending/descending chain ID doesn't seem to be a useful operation.
### Summary
In some cases, the query parameters for a MongoDB aggregation pipeline were not being initialized.
This led to errors in `GET /api/v1/vaas/{chain}/{emitter}/{seq}`.
Other endpoints could also have been affected.
Previously, when calling `GET /api/v1/governor/enqueued_vaas`, it returned a status code of 404 when there were no enqueued VAAs.
Now, the endpoint returns a status code of 200, and the response body contains an empty array.
### Summary
* On all endpoints, fix the behavior of the `page` parameter (which was previously being ignored).
* On `GET /api/v1/vaas`, fix the behavior of the `sortBy` parameter (which wasn't working when `parsedPayload=true`).
* For all endpoints, validate the query parameters `page`, `pageNumber` and `sortOrder`.
* Return descriptive errors when pagination-related parameters happen to be invalid (`page`, `pageSize`, `sortOrder`).
* Validate guardian addresses in query params.
### Testing plan
All parameters involved were manually tested.
### Summary
Split `/v1` and `/api/v1` controllers into different packages (respectively `api/routes/guardian` and `api/routes/wormscan`).
Still need to move services/repositories/models according to the new package layout.
### Summary
Updating from swaggo v1.8.9 to v1.8.10 caused issues with the generated swagger file.
The issue was solved by moving the handler for `GET /swagger.json` outside the `/doc` directory.
* add vaaId and txHash relation in vaaIdTxHash collection
* add txHash in vaas collection
* add txHash in response vaa and as filter in find vaas endpoints
walker-16
agodnic
ftocal
gipsh
gipsh