bitfinexcom / bfx-hf-algo Goto Github PK

For instance, submitted order:

Is accepted, and obviously causes:

bfx:api:ws:messages:notifications ERROR: Invalid order: minimum size for BTC/USD is 0.002

However, order continue to execute on HF side indefinitely:

2018-10-21T12:38:46.574Z bfx:hf:algo:bfx.accumulate_distribute:1111 emit self:interval_tick
2018-10-21T12:38:46.574Z bfx:hf:algo:ao-host triggering self:interval_tick for AO bfx.accumulate_distribute [gid 1111]
2018-10-21T12:38:46.575Z bfx:hf:algo:bfx.accumulate_distribute:1111 notify info: scheduled tick in ~120s
2018-10-21T12:38:46.575Z bfx:hf:algo:bfx.accumulate_distribute:1111 emit state:update
2018-10-21T12:38:46.575Z bfx:hf:algo:bfx.accumulate_distribute:1111 emit state:update
2018-10-21T12:38:46.575Z bfx:hf:algo:bfx.accumulate_distribute:1111 now behind with 1 orders
2018-10-21T12:38:46.575Z bfx:hf:algo:bfx.accumulate_distribute:1111 awaiting fill...

Ping-Ping AO fails to keep going after the first PONG gets fills.

Steps to reproduce

• setup P/P with multiple orders, e.g. Ping/Pong | -0.0002:-0.0002 @ [48360..48550] -> -10
• watch out for the first PONG to be filled

Problem

• the AO stops with bfx:hf:algo:ao-host:ws2:bind-bus error processing: TypeError: Cannot read property '1' of undefined
• (with endless : true) the filling of PONGs does not re-create any PINGs
• if the price returns into the original PING range, no more PONGS are generated (regardless of endless : true/false)

Log file

api-server.log
note: after the error and AO collapse, the remaining orphaned PONGs and original virgin PINGs are handled normally as separate atomics by the server. The log file is understandably silent on this.

Thank you for reviewing. It'd be a quite a shame if P/P remains not available in Honeyframework, also heaps of work done previously are laid too waste. :-/

Issue type

• bug
• missing functionality
• performance
• feature request

Brief description

Create an AO that maintains a buy or sell order in 1st position on the book, respecting a certain spread.

This pulll request bitfinexcom/bfx-api-node-util@9e0d87f changed the way the nonce is generated.
THe problem is that all of the default order examples use this function to also generate cId when creating an order which is now invalid due to the * 1000 multiplier

I see atomic cancellation delays were removed recently (79f857b & co); I suggest making the fields somehow optional in the UI, as with the current change no delay can be specified by calling the library directly.

See Iceberg order description on Okex: https://support.okex.com/hc/en-us/articles/115003537571-Strategy-Order-Explanation

1. Submit accumulate/distribute order.
2. Wait to appear in bfx UI.
3. Cancel from bfx UI.
4. Wait to disappear from bfx UI.
5. See in logs, that order canceled.
6. Wait some arbitrary time.
7. Restart HF service server.
8. Wait to appear same accumulate/distribute order which was canceled on step 3.

After the last bump in version the new version 1.2.0 was apparently not pushed to npm.

https://www.npmjs.com/package/bfx-hf-algo

This creates a conflict in bfx-hf-algo-server, which now depends on version 1.2.0 upon install, which is not available on npm.