NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #3209 by repository stars
Last release 4 years ago
no release in 18 months
Ships unpredictably
gaps range from 8 days to 1.1 years
Most releases are documented
notes for 10 of 13 stable releases
Nothing withdrawn
no release was ever pulled
6 years old
14 releases · first in 2020
One column per quarter.
Nothing published for this version
I noticed sometimes during chain reorganization previous entries from DB needs to be removed and new ones are required to be inserted, during that due
I noticed sometimes during chain reorganization previous entries from DB needs to be removed and new ones are required to be inserted, during that due to not using cascading removal of transactions/ events from respective DB tables for removed block header(s), conflict used to rise.
This release includes only one PR #64 , which attempts to address this problem.
Fast, lock-free, concurrent-safe job queue implementation, powering ( non-duplicated ) Block Processing
Automatic clean up of historical delivery data by independent worker [ Generally used for determining whether user has crossed allowed rate limit or n
ette deploymentUpdated chain reorganisation protection & reconsidering reorg-ed blocks
{"block", "transaction", "event"}, serving on single websocket connectionette & they can now subscribe to N many topicsImproved retry queue manager implementation, attempts to process failed blocks in delayed mode ✅
| Before 🙂 | Now 😉 |
|---|---|
| 2.6G RAM with ~99.8% CPU | 15M RAM with ~2% CPU |
Always attempt to publish block data 🚀
uuid as primary key of delivery_history table, instead of bigserial 🦾Taking snapshot of existing data store [ Concurrent ]
systemdEtteMode = 2All requests being made to /v1/graphql to be scanned by rate limiter, using APIKey provided
/v1/graphql to be scanned by rate limiter, using APIKey providedIf you're running
etteon production, you should definitely update to this version.
Now ette can help you in fetching certain event log given block number/ hash & log index in block. Both REST & GraphQL APIs support it.
Now ette can help you in fetching certain event log given block number/ hash & log index in block. Both REST & GraphQL APIs support it.
type Query {
eventByBlockHashAndLogIndex(hash: String!, index: String!): Event!
eventByBlockNumberAndLogIndex(number: String!, index: String!): Event!
}In response you'll receive 👇
type Event {
origin: String!
index: String!
topics: [String!]!
data: String!
txHash: String!
blockHash: String!
}And as it's also available using GraphQL API, you get to choose what are specific fields you want to receive in response.
For addressing Chain Reorganisation issue, implemented Redis backed delayed block processing queue 🥳
BlockConfirmations field ), it can be set, how many block confirmations are required before finally persisting blocks in DBNothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →