Skip to content

Latest commit

 

History

History
114 lines (88 loc) · 4.16 KB

guide-txn-states.rst

File metadata and controls

114 lines (88 loc) · 4.16 KB
Raw

Transaction states

On a depot open for publication, a new package version may be in the process of publication. As the package version is built up, it goes through a series of transaction states. We may also refer to these as "server states".

We phrase the state machine in terms of a single removal state, ABANDONED, which covers both the never-created package instance (even with a series of never-finished transaction events). It may be more appropriate to separate the ABANDONED state into TX_ABANDONED and PKG_DELETED.

This summary leaves us with a state transition diagram like:

           0
           |
           |
           v
  +--> TRANSACTING --> ABANDONED <--+
  |        |               ^        |
  |        |               |        |
  |        v               |        |
  |    SUBMITTED ----> INCOMPLETE   |
  |        |               |        |
  |        |               |        |
  +--- PUBLISHED <---------+        |
           |                        |
           |                        |
           +------------------------+

0 -> TRANSACTING
    On initial package creation.

TRANSACTING -> ABANDONED
    If initial package transaction never committed, commitment
    failed, or explicitly dropped.

TRANSACTING -> SUBMITTED
    On successful package transaction commitment.  Packages with
    syntax errors or immediate inconsistencies would have failed in
    commitment.

SUBMITTED:
    The package modified by the transaction is known by a specific
    version.  Its contents are in the repository.

SUBMITTED -> INCOMPLETE
    If commitment included a deferred inconsistency (package
    dependency is the only expected form), then the package is left
    in the incomplete state.

INCOMPLETE:
    The package with the specific version string is on the
    incomplete list.  Its contents are in the repository.

INCOMPLETE -> ABANDONED
    If incomplete package explicitly removed.  (Possibly by
    timeout from arrival in INCOMPLETE.)

SUBMITTED -> PUBLISHED
    If commitment had no deferred inconsistencies, then the package
    is considered ready for publication.

INCOMPLETE -> PUBLISHED
    If the deferred inconsistencies, upon reevaluation, are now held
    to no longer be inconsistent, then the package is considered
    ready for publication.

PUBLISHED:
    The package with the specific version string is present in the
    catalog.  Its contents remain in the repository.

PUBLISHED -> ABANDONED
    On manual request for package decommissioning, the package will
    be moved to the abandoned state.

ABANDONED:
    A package with a specific version string is no longer in the
    catalog or on the incomplete list.  Its contents, if they were
    in the repository, should be removed from the repository.

XXX ARCHIVED might be a special state connected to PUBLISHED, or
merely a substate.  An archived package has its manifest and
contents in the repository, but cannot be installed on a client.
The point of including ARCHIVED packages is to allow client
deduction on a system not installed by the pkg system.