Associate the harmony_task_history table with the sector

[strahe]

No description provided.

[magik6k]

Thanks a lot for this; I'd avoid the msgpack dependency, I don't think the complexity is worth the minimal savings it can get us, and it makes querying details much harder

[LexLuthr]

I would not recommend this approach at all. Changing the harmonyTask to be sector specific is not a good idea. HarmonyTask is generic for a reason. This would thrown a wrench in our plans to later do market, PDP and other things. A separate Event table would be far better. Harmony history should have nothing to do with sector events.

[strahe]

I removed the fields added to history table and used the new event table to record the history IDs.
It looks like:

[magik6k]

This looks good now, I'd still improve 2 small things, especially the schema change which will be hard to change after this lands

[LexLuthr]

I think we should record events regardless of failure or success. If we only record success, chances are we will never actually use them. Why would you check logs for working system? We should record all failures as well.

We also need some kind of cleanup mechanism for this table. It will grow very quickly on large clusters.

[strahe]

@LexLuthr Totally agree. We manage over 100 miners, so the data volume could become very large, but I'm afraid that too many changes will make this PR increasingly complex.😀I will keep records of successes and failures in this PR.

[LexLuthr]

I would say this is still a relatively smaller PR. We can add cleanup in this and mark this as a feature with documentation on how to get these events from CLI.

[strahe]

I think we should record events regardless of failure or success. If we only record success, chances are we will never actually use them. Why would you check logs for working system? We should record all failures as well.

We also need some kind of cleanup mechanism for this table. It will grow very quickly on large clusters.

I confirmed again that the history table records failed entries, so the event table will also default to recording failed entries. Regarding data growth, as Magik6k mentioned, SST compression might be helpful. It seems that the history table will impose a greater load compared to the event table.

[strahe]

List events:

# List all events
curio seal events               

# List all events for the specified actor
curio seal events --actor actor  

# List events for the specified sector and actor
curio seal events --actor actor --sector sector  

[magik6k]

This is extremely useful, thanks for the PR!