Consider tuning ancestor/descendant size limit for our use case #139
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#139
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While publishing lots of videos, @nikooo777 got:
Transaction rejected: 64: too-long-mempool-chain
Which comes from:
4ff143387e/src/main.cpp (L1249)
Which is affected by:
-limitancestorcount
-limitancestorsize
-limitdescendantcount
-limitdescendantsize
At the time it last happened, this was the mempool info output:
This issue opens a discussion on what would be the best move on this subject and if there are other solutions.
Solution I would consider: What if the node being used for large scale publishes raises this limit? Will the mempool get rejected by other nodes all the time? Would it solve or trigger another issue?
@shyba and @nikooo777 Is this still an issue? What is the impact/priority?
closing per conversation with Niko and Victor