-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pool updates not including deregistration events #240
Comments
Thanks for raising, I agree this is a missed functional test on pool cache on koios backend, will get it fixed for v1 PR (#238) |
@robinboening - For the context of this issue, could you confirm the below looks correct (as in expected) change outcome? You can find more details here, sample output below. This includes a change to
|
## Description <!--- Describe your changes --> [Re-created from #227 post renaming base-branch] - [x] pool_list: Return all fields from pool_info_cache (latest pool entry) - [x] Remove filter for returning only 'registered' pools from pool_list, pool_relays and pool_metadata endpoints - [x] Few more linting polishing (remove trailing spaces, move single column/table references onto same line) - [x] Update pool_info to return same metadata as pool_list and pool_metadata (latest w/o fallback) - [x] Update all tx_in joins to use the new tx_out.consumed_by_tx_in_id - [x] Dont include epoch_params in epoch_info_cache, update references accordingly - [x] Update `*_txs` as per #186 (point 4) - [x] Update `*_utxos` as per #186 (point 3) - [x] credential_utxos - [x] address_utxos - [x] account_utxos - [x] utxo_info - [x] asset_utxos - [x] script_utxos - [x] Add script_info and align all endpoints for scripts - [x] Add temporary cron for fixing epoch count mismatch - [x] Add pool_registrations/pool_deregistrations endpoint - [x] Add retired txs to `pool_updates` (other fields for such transactions will return `null`) - [x] Add reward_withdrawals/treasury_withdrawals endpoint - [x] Simplify address_assets and account_assets heirarchy to return flat table (helps do horizontal filtering as desired) - [x] API Spec updates: - [x] Add section for Authentication - [x] Bump Koios version - [x] pool_list - [x] pool_metadata - [x] pool_relay - [x] `*_txs` - [x] `*_utxos` - [x] `address_assets` - [x] `account_assets` - [x] `epoch_params` - [x] `pool_registrations`/`pool_deregistrations` - [x] `reward_withdrawals`/`treasury_withdrawals` - [x] All script-related endpoints - [x] Update examples - [x] Check re-usability - [x] Check schemathesis - [x] guild - [x] preview - [x] preprod - [x] mainnet - [x] Add v0 vs v1 to monitoring - [x] guild - [ ] preview (post merge) - [ ] preprod (post merge) - [ ] mainnet (post 1.1.0 - instead of 1.1.0rc) release - [x] Ogmios - [x] Add integration for tx Evaluation and submission using ogmios path - [x] Add health check based on /health (`version` and `networkSynchronization`) - [x] Update CHANGELOG - [x] Bump final specs version number to v1 ## Which issue it fixes? <!--- Link to issue: Closes #issue-number --> - [x] Closes #208 - [x] Closes #218 - [x] Closes #186 - [x] Closes #221 - [x] Closes #224 - [x] Closes #191 - [x] Closes #232 - [x] Closes #240 #241 --------- Co-authored-by: KoT_B_KocMoce <[email protected]> Co-authored-by: Ola [AHLNET] <[email protected]>
Sorry for the delay! I finally had a chance to look at the changes and it looks great to me! A few questions though. Based on the above example, imagine there was another update after the deregistration only updating pledge
If there was a reregistration after the deregistration, I assume Thank you! ~Robin |
Is v1 already available for beta use? Or is it going to be launched later in the future? |
Yes, since it is a registration entry - retiring_epoch will be null, as it will correspond to what's in the pool update [registration] certificate
It would be
All other columns will have value, since pool registration does not have empty fields for things like pool margin, fee, owners, relays, etc.
Correct
v1.1.0rc release on guild and preview should be in 24 hours (this will be in addition to continue serving v0), while for preprod and mainnet will follow after a few days of testing in the field to capture feedback |
Describe the bug
I find the response from the
pool_updates
endpoint a bit confusing. However, for this issue I want to solely focus on the fact that it doesn't include pool deregistration events, which I believe counts as updates.To Reproduce
Steps to reproduce the behavior:
pool1y2gynck9pd4en5rzm0rueqd2qm7sw89aqmkcntd899vv237qj38
This is no exception. You'll see the same behaviour if you request updates for a different retired pool, like
pool1dmpzsnuwxy44ky3dskuhmwpglumy6j0rc5wyfxlu3zym798f79g
Expected behavior
For the above example, the response should not include 2 but 4 items as are two deregistration transactions available onchain. For comparison, please see blockfrost's response in the screenshot.
Screenshots
Koios response

blockfrost response

The text was updated successfully, but these errors were encountered: