Skip to content

v1.1.3

Compare
Choose a tag to compare
@sduchesneau sduchesneau released this 18 May 15:56

Highlights

This release contains fixes for race conditions that happen when multiple request tries to sync the same range using the same .spkg. Those fixes will avoid weird state error at the cost of duplicating work in some circumstances. A future refactor of the Substreams engine scheduler will come later to fix those inefficiencies.

Operators, please read the operators section for upgrade instructions.

Operators

Note This upgrade procedure to you applies if your Substreams deployment topology includes both tier1 and tier2 processes. If you have defined somewhere the config value substreams-tier2: true, then this applies to you, otherwise, if you can ignore the upgrade procedure.

This release includes a small change in the internal RPC layer between tier1 processes and tier2 processes. This change requires an ordered upgrade of the processes to avoid errors.

The components should be deployed in this order:

  1. Deploy and roll out tier1 processes first
  2. Deploy and roll out tier2 processes in second

If you upgrade in the wrong order or if somehow tier2 processes start using the new protocol without tier1 being aware, user will end up with backend error(s) saying that some partial file are not found. Those will be resolved only when tier1 processes have been upgraded successfully.

Fixed

  • Fixed a race when multiple Substreams request execute on the same .spkg, it was causing races between the two executors.
  • GUI: fixed an issue which would slow down message consumption when progress page was shown in ascii art "bars" mode
  • GUI: fixed the display of blocks per second to represent actual blocks, not messages count

Changed

  • [binary]: Commands substreams <...> that fails now correctly return an exit code 1.

  • [library]: The manifest.NewReader signature changed and will now return a *Reader, error (previously *Reader).

Added

  • [library]: The manifest.Reader gained the ability to infer the path if provided with input "" based on the current working directory.

  • [library]: The manifest.Reader gained the ability to infer the path if provided with input that is a directory.