order 취소가 잘 안되요

[jmche]

Debug시 test로 진행할경우 order취소가 되는데, 실제 프로그램 실행시 최소가 안되요,
무슨 원인인지 파악하기가 어렵네요.

[jmche]

그냥 함수로 하면 안되는것 같고, aaa= ordercall하면 되는것 같아요

[elbakramer]

안녕하세요. 늦었지만 리포트 감사합니다.

설명을 너무 짧게 해주셔서 실제 문제가 되셨던 상황을 구체적으로 상상하기가 어려운데요.
일단 문제는 해결이 되신거 같으니, 이번 기회에 주문취소와 관련하여 일반적인 설명을 여기 덧붙여봅니다.

1.

자칫하면 사람들이 헷갈려할 수 있는 부분이라고 생각이 드는점을 짚어보자면, 최초 주문을 위한 OrderCall() 함수 호출 이후 반환되는 stream 을 cancel() 하는게 해당 주문을 취소하는 것은 아니라는 점입니다.

stream = entrypoint.OrderCall(request_name, screen_no, account_no, order_type, code, quantity, price, quote_type, original_order_no)
stream.cancel()

여기서의 cancel() 은 단순하게 "gRPC 를 통해 이후 전달받을 주문의 상태변화 이벤트들을 (접수, 체결, 잔고) 더이상 듣지 않겠다" 의 기능으로 이해하시는게 좋습니다. 이벤트를 더이상 전달받지 않더라도 만약에 해당 주문이 이미 접수처리까지 진행이 된 경우라면 해당 주문은 키움증권의 서버상에 계속 유효한 주문으로서 남아있게 됩니다.

예외적으로 만약에 실제 gRPC 서버단에서 주문요청을 키움증권측에 전송하기 이전에 stream 이 취소되면서 서버측의 연산도 취소되는 경우라면 주문요청 자체가 전송되지 못하면서 취소된 것 처럼 보일수는 있겠습니다.

2.

그래서 말씀주신 것 처럼 실제 주문취소를 위해서는 이를 위한 OrderCall() 을 다시 호출해주어야 합니다.
사실 OrderCall() 함수의 시그니쳐는 키움 OpenAPI+ 기준으로 SendOrder() 함수의 시그니쳐를 그대로 가져온 것이기 때문에 관련해 문서에서 설명하는 방식에 맞춰서 주문취소를 위한 파라미터를 설정해 호출하면 됩니다.

아래 설정은 위에서 링크한 문서에서의 매수 취소 예시 설정을 그대로 가져온 것입니다.

request_name = "RQ_1"
screen_no = "0101"
account_no = "5015123410"
order_type = 3  # 매수취소 (1:신규매수, 2:신규매도, 3:매수취소, 4:매도취소, 5:매수정정, 6:매도정정)
code = "000660"
quantity = 10
price = 0
quote_type = "00"
original_order_no = "2"  # 취소할 주문 번호

stream = entrypoint.OrderCall(request_name, screen_no, account_no, order_type, code, quantity, price, quote_type, original_order_no)

[jmche]

제가 처음은 그냥 ordercall함수를 사용하고 return되는 값을 변수에게 부여하지 않았습니다. 즉 아래와 같이
entrypoint.OrderCall(request_name, screen_no, account_no, order_type, code, quantity, price, quote_type, original_order_no)
추후에 return값을 부여해주니 문재가 발생하지 않습니다.
stream = entrypoint.OrderCall(request_name, screen_no, account_no, order_type, code, quantity, price, quote_type, original_order_no)

[elbakramer]

아 그렇군요. 이해했습니다. 이 부분은 제가 몰랐던 내용이네요.
말씀주신 부분은 gRPC 의 response-streaming 케이스에 대한 동작을 제가 좀 더 자세하게 알아봐야 할 것 같습니다.

지금 당장 추측하기로는 문제가 되었던 "리턴값이 없는 형태로 호출" 의 경우, 반환되었어야할 stream 객체가 가비지 컬렉션 따위의 처리를 당하면서 앞서 말씀드렸던 내용중에 "실제 서버측 연산 처리 이전에 cancel() 당해버리는" 것과 비슷하게 되어버리는건 아닌가 하는 생각이 드네요.

예외적으로 만약에 실제 gRPC 서버단에서 주문요청을 키움증권측에 전송하기 이전에 stream 이 취소되면서 서버측의 연산도 취소되는 경우라면 주문요청 자체가 전송되지 못하면서 취소된 것 처럼 보일수는 있겠습니다.

[elbakramer]

해당 이슈가 현재 알려주신 workaround 는 있지만 근본적으로 현재 배포중인 코드상에서 해결된 것은 아닌 상황인데요.
일단은 known issue 로 가져가고 해당 내용을 다른 사람들에게도 고지하기 위해서, 이슈가 실제로 해결될 때 까지는 해당 이슈를 다시 열어놓도록 하겠습니다.

[dh377]

해당 이슈가 현재 알려주신 workaround 는 있지만 근본적으로 현재 배포중인 코드상에서 해결된 것은 아닌 상황인데요. 일단은 known issue 로 가져가고 해당 내용을 다른 사람들에게도 고지하기 위해서, 이슈가 실제로 해결될 때 까지는 해당 이슈를 다시 열어놓도록 하겠습니다.

이런 문제는 C++ 프로그래밍에서 흔하게 발생하는 문제인데, L-Value가 없는 R-Value인 경우 (즉 FunctionCall 한 결과를 assignment할 변수가 없는 경우) 컴파일러에서 최적화를 위해 평션 콜을 아예 제외시켜버립니다. Python에서도 Generator의 객체가 변수에 저장되지 않는 경우 유사한 최적화를 하는 것 같네요. 디버거를 이용했을 때는 괜찮았다는 말은, 디버거는 리턴값을 추적하기 위해 디버거 내부적으로 L-Value(변수)에 저장하게 되면서, 펑션콜이 제외되지 않은 경우입니다.

혹은 lazy evaluation 때문에 assignment 하기전에는 연산을 하지 않는 Generator 객체의 특성 때문일수도 있습니다.

언어적 특성에서 오는 한계이니 그냥 L-Value = (assignment)를 하도록 가이드 하는 것이 맞다고 생각됩니다.