Repository navigation
Create FailedPayables Table #631
Description
We need to store all transactions generated by us that failed for various reasons, so we can track them for future use.
Keeping these transactions in the SentPayables table is not ideal. Instead, we should create a separate table for them.
We also need to update the SentPayables table to ensure there is no state called Failed; it should be renamed to Retry.
For the FailedPayables table, we will use the following structure:
create table if not exists failed_payable (
rowid integer primary key,
tx_hash text not null,
receiver_address text not null,
amount_high_b integer not null,
amount_low_b integer not null,
timestamp integer not null,
gas_price_wei integer not null,
nonce integer not null,
failure_code text not null
)This table should support all CRUD operations.
Please include this in the same migration as the SentPayables table (at the time of writing this card, the migration was from version 10 to version 11).
Before starting on this card, be sure to read the comments.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
Activity
dnwiebe commentedon May 11, 2025
From what I hear, a gas price lower than one gwei is conceivable, as is a gas price high enough that it can't be expressed as wei in 64 bits. Therefore, we probably need a two-column 127-bit value for
gas_price_wei.Unless! If we're never going to have to use the
gas_price_wei(or, for that matter, theamount_xxxcolumns) in aWHEREclause, then they don't have to be represented as numeric data types at all. We can represent them somehow as strings (perhaps a string representation of a long decimal number, perhaps a sixteen-byte (128-bit) value encoded as a Base64 string, maybe in some other way) and store them asTEXTcolumns to avoid bringing the complicated two-column logic to bear.dnwiebe commentedon May 11, 2025
Should there be some kind of status information in the row as well? For example, whether the failure is in the process of being addressed, or perhaps a retries-remaining count, or an enum with Unaddressed/InProcess/Fixed/Unfixed/Unfixable values, or whatever.
dnwiebe commentedon May 11, 2025
Think about what happens at end-of-life for a record here. Transaction information in the database is a security risk. At the very least, failures that have been resolved must be removed from this table. For more security, the sensitive parts of a transaction could be encrypted with the same logic used to encrypt some
CONFIG-table entries.If it's decided that some of the columns should be encrypted, anything encrypted will need to be of
TEXTtype; the encryption logic doesn't produce integers, even from integers.utkarshg6 commentedon May 15, 2025
Solutions for the above comments respectively:
gas_price_weishould be stored into two columns by dividing the integer, similar toamount, and this change should also be made inSentPayables.retriedcolumn in theFailedPayablestable.GH-631: store gas price wei in two columns
GH-631: more updates to the sent payable table
GH-631: eliminate all errors
GH-631: accept null values in db
GH-631: all tests passing
GH-631: use TransactionBlock everywhere
26 remaining items
GH-631: minor self-review changes
GH-631: add another review changes
GH-631: add more review changes
GH-631: introduce the replace_record() in SentPayableDao
GH-631: review 4 changes
GH-631: review 5 changes
GH-631: review 6 changes
GH-631: import the Itertools and make join work without collect
Merge branch 'master' into GH-631
Merge branch 'GH-598' into GH-631
GH-631: eliminate clippy warnings; tests will still fail due to todo!()
GH-631: Create `FailedPayables` Table (#646)
GH-598: Payments Revamp: Minimal Viable Product (#712)