blocknetdx / exrproxy-env

erp-ethserver
7 stars 10 forks source link

Update projects - Closes Issue #209 #219

Closed ConanMishler closed 1 year ago

ConanMishler commented 1 year ago

Closes https://github.com/blocknetdx/exrproxy-env/issues/209

(Also makes cli/projects.py smart enough to fetch the payment database host IP and use that IP by default.)

ConanMishler commented 1 year ago

Using True and False as index/subscript names in coin_names (lines 18-27) seems a bit odd, but later usage looks like it will work as intended.

Yeah I guess that could have been written in a slightly more readable way, but yes, it does work as intended. (The "True" and "False" index names were copied from where I used the same coin_names nested dictionary in the eth-payment-processor code. I kept it the same for consistency.)

Line 153: how do you know they're currently purchasing tokens?

There is a pending bool value for each project in the payment table of the payments db. pending is set to true for one hour after a project is initially requested via a call to request_project for a new project, or via a call to extend_project for an existing project. That 1 hour period while pending is true for a project is presumably the time when a client is most likely to be making payment to the project because that's when the client gets full api token credit for their payments instead of just half credit. In the current Payment Processor structure there is a slight risk that an SNode Op could cause a client's deposit to be ignored by the Payment Processor if the SNode Op happens to withdraw funds from a project during the exact same 20 second window when the client sends funds to the project. That's why the new --balances option added in this PR makes it clear to the SNode Op when there is a possibility that a client might be sending funds to a project - so the SNode Op can avoid that small risk entirely by not withdrawing funds while a project is in that pending state.