-
Notifications
You must be signed in to change notification settings - Fork 22
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
feat!: add inclusion claim to filecoin api #1307
base: main
Are you sure you want to change the base?
Conversation
fdc84d3
to
1663a25
Compare
BREAKING CHANGE: aggregator events context need assert service
1663a25
to
4b28943
Compare
in these cases it can help to have a commit in your branch that shows the clean diff with just the changes you want to make, and then a subsequent commit that applies just the formatting change that ci demands, so folks can review the meaningful stuff. |
Typically I would agree with you, if it would have failed in CI and I would fix. However, that is not really the case here. I always run format before the commit because my own changes would be problematic for it... I could have looked at what files were purely changed by the format (which I didn't, but also would not expect commited things to be bad wrong!). So, the core changes from lint are actually in files I changed. Anyway, this is not a big difference in the diff, so it would be needed considerable more time reverting specific changes from linting per file than eye balls ignoring the diff on these cases, which github already offers nice way to see that just formatted change. I think overall we have a problem with the linter and we should get rid of prettier because this only happens in this repo |
nb: { | ||
content: record.aggregate, | ||
includes: record.piece, | ||
proof: record.proof, |
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.
What is proof here?
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.
proof is the CID of the dag-cbor block that we encode the proof on for storing it
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.
https://us-west-2.console.aws.amazon.com/dynamodbv2/home?region=us-west-2#item-explorer?operation=SCAN&table=prod-w3filecoin-aggregator-inclusion-store the inclusion store is storing it map, to the proof bytes
BREAKING CHANGE: aggregator events context need assert service
Apologies for the noise from some formatting changes, but this was from running
pnpm format
which was needed to make the CI happy 🤷🏼♂️Similarly to how we issue
piece/accept
from insert event oninclusion-store
, we can also use this event to issueinclusion/claim
atomically. Therefore, we create a new event handler thatw3filecoin-infra
can wire up with a lambda from event on dynamo insert eventCloses: #1275