paritytech / paritytech/jamtart

Work-package pipeline improvements

Open
#35 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
18
Forks
3
Avg merge
3d 15h
Merged PRs (30d)
3

Description

The current pipeline stage display order is alphabetical. We should show pipeline stages in the order they happen, ie:

  • Received
  • Authorized
  • Refined
  • Report Built
  • Guarantee Built
  • Distributed

Failure can happen at any point, probably makes sense to just show "Failed" at the end. That said it would maybe be nice to bin failures by pipeline stage... this is not included in the Failed event but can be inferred by the previous events for the work-package.

Note that the first four stages happen on all three guarantors for the core (or at least two, we allow one to fail). For the summaries I would suggest we just include the primary guarantor (maybe this is what is happening already?) and possibly add some stages to cover the secondary guarantors. Maybe "Shared" for successfully sent to at least one secondary and "Signature Received" for got at least one secondary signature? These really happen in parallel but we could stick "Shared" after "Authorized" and "Signature Received" after "Report Built".

Finally, we should add the on-chain stages. At least "Reported" (guarantee included in a block) and "Available" (sufficient assurances received). "Accumulated" would be great although it's not so straight-forward to determine this. "Finalized" would also be nice but would only make sense if we had "Accumulated".

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by locating the pipeline stage display and the work-package events, then trace how guarantor and on-chain stages are represented. Done should include a defined ordering for existing stages and an agreed scope for secondary-guarantor and on-chain stages.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.