OCW Rework

[jimmychu0807]

@stiiifff
Actually I think about it, with the current design on OcwNotification, we don't need to use locks.

pub OcwNotifications get (fn ocw_notifications): map hasher(identity) T::BlockNumber => Vec<ShippingEventIndex>;

Because for every ocw run corresponding to each block, only the queue of that block is processed. There is no overlapping, or double-processing here. In fact this is quite an elegant design, better than having just a single task queue (the previous design).

[jimmychu0807]

@stiiifff @riusricardo
I am looking at the CI failure. How come compiling substrate v2-rc4 would fail? Does this happen to any of you?

https://github.com/stiiifff/pallet-product-tracking/pull/23/checks?check_run_id=880662075

[jimmychu0807]

This is to be fixed once a Substrate has a new release of this PR.

[stiiifff]

@stiiifff
Actually I think about it, with the current design on OcwNotification, we don't need to use locks.

pub OcwNotifications get (fn ocw_notifications): map hasher(identity) T::BlockNumber => Vec<ShippingEventIndex>;

Because for every ocw run corresponding to each block, only the queue of that block is processed. There is no overlapping, or double-processing here. In fact this is quite an elegant design, better than having just a single task queue (the previous design).

I agree we can keep it simple for the sample, but I also find it nice to expose devs to some intricacies of working with off-chain workers (and proposing a reusable pattern). Also, I think it'd be best if the worker can deal with transient listener issues, see another take in the refactor-ocw branch.

[jimmychu0807]

Refer to: #20