SCP-3127: Chain index as a library #186
Conversation
sjoerdvisscher
force-pushed
the
SCP-3127-chain-index-library
branch
from
fae65c8 to
1ea4283
Compare
sjoerdvisscher
force-pushed
the
SCP-3127-chain-index-library
branch
from
cf9d84a to
0df9c03
Compare
sjoerdvisscher
changed the title
| -> Eff (ChainIndexQueryEffect ': ChainIndexControlEffect ': BeamEffect ': effs) a | ||
| -> Eff effs (Either ChainIndexError a) | ||
| handleChainIndexEffects RunRequirements{trace, stateTVar, conn, securityParam} action = do | ||
| state <- liftIO $ STM.readTVarIO stateTVar |
There was a problem hiding this comment.
Is this safe? You are reading the state in a transaction, then doing some computation, then saving the state in a transaction, what if some other thread reads the old state while you are doing the computation? Shouldn't there be an atomic block around all this section?
There was a problem hiding this comment.
Good point. It was already like this.
There was a problem hiding this comment.
I changed the TVar to an MVar since this basically means we can't handle chain index effects concurrently.
| @@ -102,6 +102,7 @@ runChainSync socketPath trace slotConfig networkId resumePoints chainSyncEventHa | |||
|
|
|||
| pure handle | |||
| where | |||
| chainSyncEventHandler evt _ = onChainSyncEvent evt | |||
There was a problem hiding this comment.
Here we are ignoring the second argument for all our handlers. Can we just remove it from ChainSyncCallback? This is I guess the computed slot number (computed given local time and slotting information) which we don't need to send to a client since it can compute it itself.
There was a problem hiding this comment.
I had that at first, but then ran into an issue with the mock implementation in the PAB that still used it.
sjoerdvisscher
force-pushed
the
SCP-3127-chain-index-library
branch
from
8b764bc to
8e63d55
Compare
Refactoring so the chain index can be used more easily as a library, with the following goals.
Plutus.ChainIndex.Libwhich collects and documents what's needed to run a chain index.The main focus in this PR is on
ChainSyncHandlers, since customising what to sync and store is the biggest request (seefilterTxs), and to make it easy to run the syncing once you have built such a handler.This is just a first step, we expect to be building this out over the coming months.
Pre-submit checklist: