About error handling of ExecuteHttpRequest

yunkon-kim commented 6 days ago

vNet/subnet 자원을 Refine하는 기능을 개발하는 과정에서 파악한 사항으로, 자원 유무를 조회 한 다음, 어떤 로직이 처리되는 대부분의 케이스에 잠재된 이슈가 있어 보입니다.

vNet/subnet refine 과정은

Tumblebug에 저장된 Object를 신뢰할 수 있는 정보로 보고,
Spider API를 통해 해당 자원을 조회 한 후,
없다면 Object를 삭제하는 절차로 진행됩니다.

Spider에서는 자원이 없는 경우 404 에러가 리턴되고 있습니다. 그래서 자원 조회 요청 후, 에러이면 Refine 하는 로직이 적용되어 있습니다.

이슈가 되는 케이스는, 자원이 실제로 있어서 Refine할 필요가 없는데, 조회를 처리하는 과정에서 다른 에러가 발생 한 경우 입니다. (예, 404 이외의 에러 코드가 발생한 경우) 이 경우, 자원이 있음에도 Refine 처리될 것 입니다...

ExecuteHttpRequest의 관련 코드:

https://github.com/cloud-barista/cb-tumblebug/blob/a0bc69f75ca46f508376025dc7c9eb0a822b5317/src/core/common/client.go#L211-L218

코드 분류 하는 방법을 시도해 보았으나 적절하지 않다고 판단하였고, 일단 이슈를 오픈해 놓으려고 합니다.

seokho-son commented 16 hours ago

@yunkon-kim

Spider의 DB 상에는 등록되어 있는 자원을, 실제 CSP에서 찾을 수 없으면 404를 리턴하고 있다는 의미가 맞나요? (아니면, Spider DB상에 등록되어 있지 않은 자원인 경우 404 리턴?)

말씀주신 것과 같이, SP에서 에러코드가 일관적으로 제공되지 않으면, 에러코드를 기준으로 핸들링하는 것이 까다롭긴합니다만..

yunkon-kim commented 15 hours ago

@seokho-son

Spider의 조회 API를 호출 했을 경우, 자원이 없으면 404 리턴 되는 상황을 나타냅니다. 말씀하신 Spider 내부의 상황도 중요하겠습니다만, Tumblebug 기준에서는 어느 특정 케이스(문의하신 둘 중 하나라도)에 위 사례가 나타난다면 이슈가 되기에 공유드렸던 부분입니다.

(추가로, Error code 정비 및 이를 일관되게 제공하는 것은 쉽지 않은 작업일 것으로 생각합니다. Server-client 양 단의 개선도 예상됩니다.)

powerkimhub commented 15 hours ago

@yunkon-kim @seokho-son

현재, Spider에서도 404 처리 제대로 못하고 있습니다.
Swagger 정의만 분리되어 있는 상태입니다.
추후 개선해야 할 사항이에요.

[현황]

대부분 500 Internal Server Error로 에러 처리


curl -vX GET http://localhost:1024/spider/vpc/abc?ConnectionName=aws-config01 -H 'Content-Type: application/json'
Note: Unnecessary use of -X or --request, GET is already inferred.

Trying 127.0.0.1:1024...
Connected to localhost (127.0.0.1) port 1024 (#0)

GET /spider/vpc/abc?ConnectionName=aws-config01 HTTP/1.1 Host: localhost:1024 User-Agent: curl/7.81.0 Accept: / Content-Type: application/json
Mark bundle as not supporting multiuse < HTTP/1.1 500 Internal Server Error < Content-Type: application/json; charset=UTF-8 < Vary: Origin < Date: Thu, 19 Sep 2024 02:04:58 GMT < Content-Length: 49 < {"message":"aws-config01, abc: does not exist!"}
Connection #0 to host localhost left intact

seokho-son commented 15 hours ago

@yunkon-kim

일단, http call 처리에서는 현재 에러 코드 단위의 핸들링이 쉽지 않으므로, 현재와 같이 유지하되,

원하시는 처리는 아무래도, 상위 관리 함수에서 처리해야 할 것 같습니다. (향후, 다른 리소스 처리에 대한 함수들도 필요하다면 이와 같이 처리)

SP의 DB상 ID 존재 여부 확인 -> 오류 발생 -> (추가 검증) 실제 CSP 리소스 존재 여부 확인 (SP의 org api 등 활용) -> 2개의 결과에 따라 적절히 대응

어떠신가요?

yunkon-kim commented 12 hours ago

@seokho-son

동일한 이슈를 두 번 겪는 것으로 생각되는데요 ? ^^;;

예를 들어,

SP의 DB상 ID 존재 여부 확인 -> 오류 발생 : SP DB 상 자원에 대한 metadata가 없으면 -> 오류 리턴 : SP DB 상 자원에 대한 metadata 유무 확인 과정에서 별도의 이슈 발생 -> 오류 리턴 : 위 두 오류의 구분이 난해함
(추가 검증) 실제 CSP 리소스 존재 여부 확인 (SP의 org api 등 활용) : CSP에 실제 자원이 없는 경우 -> 오류 리턴 : CSP에 실제 자원 유무를 확인하는 과정에서 별도의 이슈 발생 -> 오류 리턴 : 위 두 오류의 구분이 난해함

Q. SP의 org API는 어떤 API를 말씀하시는 것일까요? 확인을 위해, org로 검색해 봤을 때 다음과 같이 5개의 API만 검색이 되어 문의 드렸습니다.

yunkon-kim commented 11 hours ago

추가로, 현 시점에 깊게 논의할 사항은 아닌 것 같습니다. 추후 적절한 시점에 반영 PR 올리도록 하겠습니다.

관련 자료 및 선례들이 있어 공유드리오니, 가볍게 살펴보시면 될 것 같습니다. (단순 참고자료)

Overview of Status Codes, https://datatracker.ietf.org/doc/html/rfc7231#section-6.1
Empty list, HTTP status code 200 vs 204 vs 404, https://apihandyman.io/empty-lists-http-status-code-200-vs-204-vs-404/#the-context
데이터가 없을 때 200인가 404인가?, https://techblog.yogiyo.co.kr/%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B0%80-%EC%97%86%EC%9D%84-%EB%95%8C-200%EC%9D%B8%EA%B0%80-404%EC%9D%B8%EA%B0%80-f1c8c39ca9df
HTTP GET Request Status 204 Vs 404, https://stackoverflow.com/questions/34312023/http-get-request-status-204-vs-404

seokho-son commented 10 hours ago

@yunkon-kim 넵 확인 감사합니다.

cloud-barista / cb-tumblebug

About error handling of ExecuteHttpRequest #1819