Save blockchain message #120
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
neekolas
force-pushed
the
08-28-save_blockchain_message
branch
4 times, most recently
from
f7b21e2 to
9724bcf
Compare
neekolas
force-pushed
the
08-28-save_blockchain_message
branch
from
9724bcf to
3c2bcb8
Compare
| s.logger.Debug("Inserting message from contract", zap.String("topic", topic)) | ||
|
|
||
| if _, err = s.queries.InsertGatewayEnvelope(ctx, queries.InsertGatewayEnvelopeParams{ | ||
| // We may not want to hardcode this to 0 and have an originator ID for each smart contract? |
There was a problem hiding this comment.
Understanding this a little bit better - what other smart contracts are we envisioning here? Is this related to sharding?
There was a problem hiding this comment.
And maybe upgradeability. At some point we are going to replace the smart contract and we have some more optionality if we've designed around it having its own originator ID where we can handle payloads differently.
Smart contract cutover would be a complicated migration to synchronize and I don't have all the answers on how to do it. But more options feels better.
| OriginatorID: 0, | ||
| OriginatorSequenceID: int64(msgSent.SequenceId), | ||
| Topic: []byte(topic), | ||
| OriginatorEnvelope: msgSent.Message, // TODO:nm parse originator envelope and do some validation |
There was a problem hiding this comment.
We can probably share this validation code, if you don't want to deal with it
|
|
||
| s.logger.Debug("Inserting message from contract", zap.String("topic", topic)) | ||
|
|
||
| if _, err = s.queries.InsertGatewayEnvelope(ctx, queries.InsertGatewayEnvelopeParams{ |
There was a problem hiding this comment.
Is it right that we don't ever expect to process the same log twice? If so, is it problematic if we run into a unique constraint error here (which would mean the (originator ID, sequence ID) tuple already exists)?
There was a problem hiding this comment.
We could if we have two instances of the replication node running, and both are indexing the chain.
If a node gets shut down mid-block, it'll also restart at the top of that block.
The only hard constraint is that they are both processing messages in ascending order.
tl;dr