Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order only succeeds when logged in once via browser #77

Open
coveritytest opened this issue Mar 14, 2022 · 18 comments
Open

Order only succeeds when logged in once via browser #77

coveritytest opened this issue Mar 14, 2022 · 18 comments
Assignees
Labels
bug Something isn't working

Comments

@coveritytest
Copy link

coveritytest commented Mar 14, 2022

I do have some strange errors when ordering:

2022-03-09 18:37:57,586 CRITICAL MainThread      400
2022-03-09 18:37:57,586 CRITICAL MainThread      {"errors":[{"text":"order.error.128"}]}

2022-03-14 11:42:02,077 CRITICAL MainThread      500
2022-03-14 11:42:02,077 CRITICAL MainThread      {"errors":[{"text":"Internal server error"}]}

Unfortunately there is no more debug output despite I set

level=logging.DEBUG

I just found out that at least the

{"errors":[{"text":"Internal server error"}]}

error is gone, when I login to degiro once via browser. I guess this is a bug. The session is created correctly:

2022-03-14 12:08:17,645 INFO MainThread get_session_id:response_dict: {'isPassCodeEnabled': True, 'locale': 'de_DE', 'redirectUrl': 'https://trader.degiro.nl/trader/', 'sessionId': 'xxxxxxxxx.prod_a_116_4', 'status': 0, 'statusText': 'success'}

Might always happen after a weekend, when I did not login for a long time, but not sure. No, happened this morning again. Always have to login first, until buy order is executed.

@coveritytest
Copy link
Author

This can be reproduced regularly on my account, does nobody else have this problem?

@TommasoBendinelli
Copy link

I also have the same issue. Any solution?

@TommasoBendinelli
Copy link

Could it be that you need to "sleep" in between two calls to the api enough time?

@TommasoBendinelli
Copy link

I have it also this morning

@coveritytest
Copy link
Author

I wait between buy orders for 5 seconds, but it might be necessary to wait between every API call, will try this. The {"errors":[{"text":"order.error.128"}]} error happens not so often and cannot be reproduced on my site.

@funnel20
Copy link
Contributor

funnel20 commented Apr 28, 2022

@coveritytest I'm glad you brought this up, since I have the same experience.
It's certainly not related to a timeout issue between consecutive API calls, see my remark in this post.

Work-around

  1. Our script with the DeGiro Connector (API) runs dedicated on laptop 1.
  2. We start it 1.5 hours before New York Market opening and let it run for 9 hours in total
  3. Together with the start of the script, we login to DeGiro web portal on laptop 2.
  4. After a random amount of time, the web portal on laptop 2 is logged out automatically.
  5. Orders created with the API on laptop 1 will be executed without issues.

When we omit step 3, step 5 will fail with errors.

Observations

  • Since we use 2 different laptops, nothing can be set on the local machine. So DeGiro must link something to the account.
  • Since the API error is introduced after time (i.e. when not logged in to the web portal for 1 day) it seems to relate to something as an OAuth expiration.
  • Apparently the login to the web portal does something else to the DeGiro account server, than the API connect() method. @Chavithra Do you have any idea what this difference might be?

@TommasoBendinelli
Copy link

I agree that the login process for the web portal is different from DeGiro's API connect() method.
I have noticed that if you log in via the browser or your phone, no errors pop up until midnight of the next day .
So right now I am logging in into Degiro every morning as workaround, so that I am sure my daily orders will go through. But it isn't very pleasant experience, and goes against principle of having automated API where everything supposed to be automated without user intervention.

@TommasoBendinelli
Copy link

I can also support and try to find the bug if @Chavithra you can point me out where do you think this is coming from

@Henriquem-pt
Copy link

I have the same issue as well..

@pereira1408
Copy link

Same issue here.
Following for a solution!

@TommasoBendinelli
Copy link

Any news about this?

@Chavithra
Copy link
Owner

Nice analysis.

Will try to reproduce it this month.

Questions :

  1. Which action fail exactly (create, update, delete order) ?
  2. What is the duration of these orders ?
  3. Did you try to force connect() everyday ?

@funnel20
Copy link
Contributor

Nice analysis.

Will try to reproduce it this month.

Questions :

  1. Which action fail exactly (create, update, delete order) ?
  2. What is the duration of these orders ?
  3. Did you try to force connect() everyday ?
  1. When we create the first order of the day, check_order() throws TimeoutError exception. Our script handles this by a connect() and upon success retries the check_order(). This will return None.
  2. It's a day order with some variables:
order = Order(
    action = Order.Action.BUY,
    order_type = Order.OrderType.LIMIT,
    price = price,
    product_id = product_id,
    size = amount,
    time_type = Order.TimeType.GOOD_TILL_DAY
)
  1. Yes, see answer 1.

I hope this helps for your analysis.

@pereira1408
Copy link

I agree with @funnel20.

If I do not perform a login via browser besides degiro connector once a day, sell and buy orders fail. It's difficult to say those are the only actions failing because I only need to delete an order if it exists.
And yes, I've tried to force reconnection. Indeed, I even implemented a connection step before creating a buy/sell order. Even with this "workaround", it still fails.

I was thinking about the issue and, a dirty solution to temporarily mitigate the problem would be the implementation of a browser login with chrome driver working in parallel to connect() function. It's far from ideal, but It can work (desperate times call for desperate measures)

Good day for you guys :)

@Henriquem-pt
Copy link

Did someone manage to solve this without having to manually log in ?

@nine1zero
Copy link
Contributor

Never had the issue actually, using 2fa auth and running the script from a Google cloud function

@fmcruz
Copy link

fmcruz commented Oct 5, 2022

Hey, I have the same issue. Any solution/fix?

@nobodyguy
Copy link

Same issue here

@Chavithra Chavithra self-assigned this Jan 1, 2024
@Chavithra Chavithra added the bug Something isn't working label Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants