This change implements a mechanism to retransmit orders if some of the
order's selected regions do not confirm transmission in due time. It
adds a worker to repeatedly check the orders and determine if they need
retransmission. Such orders will be added to a new table named
tx_retries. The tx_start function now first checks if there are regular
new paid orders to transmit. If not, it will check the retransmission
table and retransmit an order from there if one is available.
This patch also introduces a new order state called "retranmission". The
order enters this state while waiting for retransmission.
Users can provide a list of regions to POST /order requests. This list
indicates on which regions the order should be transmitted. It also
determines the expected transmission and reception confirmations.
This change removes the infinite transmission loop with sleep periods
between each transmission. Now, a new transmission can start by a call
to "tx_start" on the following two conditions:
1) As soon as the application starts (if there is a previously paid
order waiting already).
2) As soon as the current transmission ends. The server will immediately
look for the next order ready for transmission and start it if
available.
Meanwhile, the condition for ending the current transmission (i.e., for
calling "tx_end(order)") is when all Tx confirmations are received from
all regions.
If the env var is not defined, fall back to a random string. However,
note the random string won't work over gunicorn if using multiple
workers. In this case, it is necessary to define the env var.
- If a staging_/prod_/misc_ tag is present, or if merging to master,
push the Satellite API image upstream.
- Tag images with the commit SHA and the commit ref slug (.e.g, branch
name) for caching. Tag with latest if merging to master.
- Deploy the image specified by commit SHA.
The new server implementation in Python implements request validation
using the Marshamallow package. With that, some requests are validated
directly by the marshmallow validator and do not return custom error
codes. Drop those error codes and other unused ones. Review the README
docs accordingly.
- Preserve the SQLite database and use SQLAlchemy to wrap db
interactions.
- Use Alembic for database migrations.
- Organize all the python modules on the new server/ directory.
- Use pytest for unit tests and organize test modules at server/tests/.
Many Lightning wallets do not support payments below 1 sat (in
millisatoshis). For wider compliance, set a lower limit of 1 sat on orders,
while preserving the minimum bid per byte requirement for orders whose absolute
bid exceeds 1 sat.
