* add 2 new tasks for collecting chain activity every day and hour
* making progress
* change query 2
* add query by month and year
* changes on task
* more changes
* change to 1d
* add 1d
* fix query
* adjust queryies
* change the way the query is executed
* changes on query
* making more progress
* fix per year query
* add a second group of tasks for downsampling
* add app_id
* update swagger docs
* optimize new tasks
* fix W
* fix W
* start using the new measurement
* change endpoint signature
* update endpoint name
* fix indents
* code review changes
* remove unnecessary break
* start
add search by chain
change chainId query param handling
change condition
only from chain
change query
add filter by appId
add payload type for operations query
add logs
add log for error in mongodb call
add more logs and recover to find possible panic
change type to float64
add more logs for troubleshooting
add more logs for troubleshooting payloadType query param
add another defer
* change query
* add exclusiveAppId,sourceChain and targetChain
* unify search criteria
* change queryies
* combine query params filters
* change implementation of sourceChain and targetChain
* insert filtering by chain and by appid as stages in aggregation pipeline
* fix appIds matching condition
* move query to a separate pipeline which starts from parsedVAA
* adjust query by appId
* add matching also for standardizedProperties
* change
* try using instead of
* simplify query
* add queryLoggging and remove other parts of the query to troubleshooting
* working
* add index creation
* update swagger docs
* tweak index performance and fix timestamp on parsedVaa collection
* start
add search by chain
change chainId query param handling
change condition
only from chain
change query
add filter by appId
add payload type for operations query
add logs
add log for error in mongodb call
add more logs and recover to find possible panic
change type to float64
add more logs for troubleshooting
add more logs for troubleshooting payloadType query param
add another defer
* change query
* add exclusiveAppId,sourceChain and targetChain
* unify search criteria
* change queryies
* combine query params filters
* change implementation of sourceChain and targetChain
* insert filtering by chain and by appid as stages in aggregation pipeline
* fix appIds matching condition
* move query to a separate pipeline which starts from parsedVAA
* adjust query by appId
* add matching also for standardizedProperties
* change
* try using instead of
* simplify query
* add queryLoggging and remove other parts of the query to troubleshooting
* working
* add index creation
* update swagger docs
* tweak index performance and fix timestamp on parsedVaa collection
* add lookup for globaltransactions
### Description
This pull request adds the parameter `toChain` to the endpoint `GET /api/v1/vaas/{emitterChain}/{emitterAddress}`.
Other VAA-related endpoints do not support this parameter.
Additionally, for performance reasons, a composite index must be created in MongoDB: `db.parsedVaa.createIndex({"emitterChain": -1, "emitterAddr": -1, "rawStandardizedProperties.toChain": -1, "indexedAt": -1})`
* Replace start_time and end_time query parameters with fixed ranges at the endpoint of the chain activity
Add InfluxDB tasks for enpdoint chain-activity for each timeSpan
Add cache for chain-activity endpoint
* Code review updates
### Summary
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/385
This pull request implements a new endpoint, `GET /api/v1/transactions`, which will be consumed by the wormhole explorer UI.
The endpoint returns a paginated list of transactions, in which each element contains a brief overview of the transaction (ID, txHash, status, etc.).
It exposes offset-based pagination via the parameters `page` and `pageSize`. Also, results can be obtained for a specific address by using the `address` query parameter.
The response model looks like this:
```json
{
"transactions": [
{
"id": "1/5ec18c34b47c63d17ab43b07b9b2319ea5ee2d163bce2e467000174e238c8e7f/12965",
"timestamp": "2023-06-08T19:30:19Z",
"txHash": "a302c4ab2d6b9a6003951d2e91f8fdbb83cfa20f6ffb588b95ef0290aab37066",
"originChain": 1,
"status": "ongoing"
},
{
"id": "22/0000000000000000000000000000000000000000000000000000000000000001/18308",
"timestamp": "2023-06-08T19:17:14Z",
"txHash": "00000000000000000000000000000000000000000000000000000000000047e7",
"originChain": 22,
"destinationAddress": "0x00000000000000000000000067e8a40816a983fbe3294aaebd0cc2391815b86b",
"destinationChain": 5,
"tokenAmount": "0.12",
"usdAmount": "0.12012",
"symbol": "USDC",
"status": "completed"
},
...
]
}
```
### Limitations of the current implementation
1. Doesn't return the total number of results (this may result in a performance issue when we filter by address)
2. Can only filter by receiver address (we don't have sender information in the database yet)
### Summary
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/275
This pull request implements the endpoint `GET /api/v1/top-chain-pairs-by-num-transfers`, which returns the chain pairs that have the most transfers.Internally, the endpoint uses data summarized daily to speed up query execution times.
This endpoint has a mandatory query parameter named timerange, which must be set to `7d`, `15d` or `30d`.
### Summary
Tracking issue: https://github.com/wormhole-foundation/wormhole-explorer/issues/276
This pull request implements the endpoint `GET /api/v1/top-assets-by-volume`, which returns the assets that have the highest volume. Internally, the endpoint uses data summarized daily to speed up query execution times.
This endpoint has a mandatory query parameter named `timerange`, which must be set to `7d`, `15d` or `30d`.
### 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
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
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)
### 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
* 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.
* 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
* Adds api in go
* renames observation import in api
* Add signed_vaa endpoint [guardian api]
* Add governor endpoints to API
* fix devnet/api.yaml to up with a fixed port
Co-authored-by: Gabriel Zimmermann <gabrielemanuel@gmail.com>