-
Notifications
You must be signed in to change notification settings - Fork 44
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
fix(schema): Rollback v15 ProveCommitAggregate param schema to match #907
Conversation
|
||
-- network v15 network upgrade epoch | ||
WHERE height > 1594679 | ||
AND method = 'ProveCommitAggregate'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This limits the update to only the messages in parsed_messages
table (no other) since the upgrade epoch and for this specifically affected message type. The cost will grow the longer that v0.8.6-v0.8.7 is run before updating to v0.8.8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is slick!
One concern I have: we will need to apply this migration to all messages with params containing bitfields, I think this include more than just the ProveCommitAggregate
params. Perhaps there is a query that could find all these types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can definitely do a manual search to see which types need adjusting and write a migration for each. 👍
'{"rle":', params->'SectorNumbers'->>'RLE', | ||
',"elemcount":', params->'SectorNumbers'->>'Count', | ||
',"_type":"bitfield"}' | ||
)::jsonb, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This creates a JSON literal which is cast to a jsonb
. It interpolates the existing values into the schema with the original keys.
After discussion aside w @frrist we aren't sure whether we want to include a migration with the fix as it would allow uncaught invariants to continue existing when we can be certain of accuracy by deleting and re-walking over the affected epochs (which would be communicated via docs/notices). So for live node operators, the application of this fix looks something like:
This is being parked until our in-sync discussion tomorrow. Comments welcome. |
I too think we can live without a migration and fix manually. The most important thing are the dumps, which cannot be fixed by migration anyways. |
Can you create an issue with the |
e37da77
to
1fcc11a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please merge after a 🟢 CI
We agreed to remove the migration so it could be applied as required by the use case along w documentation describing the bug (which will be limited to live data). Our data archive will correct this bug with an appropriate announcement of it's completion. |
fixes #904