Skip to content

Rework rollback operations #27

Open
@hsanjuan

Description

@hsanjuan

Currently a rollback is just a forced state-update on the operation log to whatever state the user deems fit.

This is implemented via a stateOp which are identified when we try to deserialize a user operation and fail to do so: https://github.com/libp2p/go-libp2p-raft/blob/master/fsm.go#L51

That failure relies on a decoder feature (ErrorIfFieldNotSet https://github.com/libp2p/go-libp2p-raft/blob/master/codec.go#L44) and assumes that the user-provided operation does not have a State field like the stateOp has.

There should be a way of identifying a stateOp which does not rely on the decoder error-ing. Additonally, stateOp should probably have the State field renamed to avoid any conflicts.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low: Not priority right nowexp/noviceSomeone with a little familiarity can pick uphelp wantedSeeking public contribution on this issuestatus/readyReady to be worked

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions