Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

new-yieldgen-algo bot crash, possible bug (fix) #195

Open
CohibAA opened this issue Aug 16, 2015 · 3 comments
Open

new-yieldgen-algo bot crash, possible bug (fix) #195

CohibAA opened this issue Aug 16, 2015 · 3 comments

Comments

@CohibAA
Copy link
Contributor

CohibAA commented Aug 16, 2015

I encountered a situation that caused the new-yieldgen-algo.py maker bot to crash. Reviewing the logs, I believe this was the flow - I can provide full logs by request if someone wants to look into this further.

  1. takerA fills order which used oid 4, mixdepth 3
  2. order is filled and propagated normally, utxos removed properly, afaict
  3. neworders shows 1 through 4, oldorders shows 1 through 5
  4. new_old_diff and old_new_diff only show 4, (no oid5!). can_orders is empty, ann_orders shows oid 4
  5. 5 is not removed when new orders are announced
  6. takerB fill order which used oid 4, mixdepth 0
  7. order is filled and propagated normally, utxos removed properly, afaict
  8. neworders shows 1 through 3, oldorders shows 1 through 5 still, with 4 and 5 now overlapping maxsize
  9. new_old_diff and old_new_diff do not show any changes, can_orders is empty, ann_orders is empty
  10. takerC fills order which used oid 4, mixdepth 0
  11. maker bot crashes with Exception: Not enough funds

I reviewed some old logs for the new-yieldgen-algo bot, and discovered that can_orders has never returned anything other than empty, from what I found. It seems I just never had the required fill flow to create this situation previously, as the ann_orders were lucky enough to replace the uncancelled oids most of the time.

From comparing maker bot methods, I think something is buggy in these lines. I am testing a fix to use the method in #99 instead and will update this issue accordingly.

@CohibAA
Copy link
Contributor Author

CohibAA commented Aug 17, 2015

Replacing this with these lines instead seems to fix this issue, FYI.

@chris-belcher
Copy link
Collaborator

I think I ran into this bug as well.

Your code is shorter. I think there was a reason I rewrote it into the far longer method currently used. I don't remember the reason though, maybe it was nothing, or probably just something aesthetic.

@chris-belcher
Copy link
Collaborator

added commit dc1aa21
I believe this bug arose because of a bad way of comparing lists of orders (using zip()) which failed when the lists were of unequal length.
Also changed some of the variable names to make it slightly easier to understand.
Not tested in depth

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants