feat(solver/app): basic event processor #2386
Conversation
corverroos
force-pushed
the
corver/solverlogic
branch
2 times, most recently
from
62f8f91 to
c0c6198
Compare
corverroos
force-pushed
the
corver/solverlogic
branch
from
c0c6198 to
e070b39
Compare
| req, _, err := deps.GetRequest(ctx, chainID, reqID) | ||
| if err != nil { | ||
| return errors.Wrap(err, "current status") | ||
| } else if event.Status != req.Status { |
There was a problem hiding this comment.
does it make sense to also check for case where event status is further than request status and mark it as a bug? so event status is fullffilled but request status is pending, because if this happens (if it can) we might miss a bug here.
There was a problem hiding this comment.
yeah, good point, I'll add this in next PR
| ignored = "" | ||
| ) | ||
|
|
||
| func TestEventProcessor(t *testing.T) { |
| ) | ||
|
|
||
| var ( | ||
| inboxABI = mustGetABI(bindings.SolveInboxMetaData) |
There was a problem hiding this comment.
nit: use the Golang init function pattern instead of mustGet*
There was a problem hiding this comment.
init should be avoided at all costs I think
| ) | ||
|
|
||
| // procDeps abstracts dependencies for the event processor allowed simplified testing. | ||
| type procDeps struct { |
There was a problem hiding this comment.
nit: this should be an interface, interface is used to do exactly what the comment says "abstracts dependencies for ... allowed simplified testing"
There was a problem hiding this comment.
it is a style thing, I prefer funcs, since the implementations are not related, this allows better decoupling,
| return deps.Reject(ctx, chainID, req, reason) | ||
| } | ||
|
|
||
| return deps.Accept(ctx, chainID, req) |
There was a problem hiding this comment.
Can you explain why we don't Fulfill at this step?
There was a problem hiding this comment.
First Accept, if that succeeds, then fulfil
Basic solver architecture based on a well-abstracted event processor.
issue: #2384