throttled-py의 백엔드 연동 기여 (3) - store 장애를 503으로 옮기며, 프레임워크의 예외 디스패치 규칙에 맞추기
안녕하세요, s3ich4n 입니다.
이번 게시글도 제가 기여하고 있는 오픈소스 throttled-py 이야기입니다.
지난 글에서 FastAPI 연동을 merge 직전까지 다듬은 과정을 다뤘다면, 이번에는 그 뒤에 이어진 버그 수정 PR 하나를 정리했습니다.
라이브러리에 이슈가 나더라도 이를 관리하지 않고 General 한에러가 노출되던 경로를 어떻게 라이브러리 범위 안으로 관리하도록 수정한지에 대한 이야기입니다. 특히 아래 이야기에 좀 더 집중했습니다.
- "정확히 일치하는 예외 핸들러만 보던" 첫 구현이 왜 프레임워크와 어긋났는지, 리뷰에서 받은 MRO 기반 디스패치 제안을 어떻게 적용했는지, 그리고 그 제안을 글자 그대로 쓰지 않고 FastAPI의 내부 구조인 Starlette의 기본 미들웨어 동작까지 들여다보며 살펴본 내용을 함께 적었습니다.
- 아울러 오너의 리뷰 제안일수록 승낙하고 그대로 복사하고 싶어지지만, 프레임워크가 실제로 어떻게 동작하는지 소스로 확인하고 한 겹 더 파는 것까지가 리뷰 적용이라고 느꼈던 과정을 썼습니다.
>> 링크 클릭하기 <<
감사합니다.
이번 게시글도 제가 기여하고 있는 오픈소스 throttled-py 이야기입니다.
지난 글에서 FastAPI 연동을 merge 직전까지 다듬은 과정을 다뤘다면, 이번에는 그 뒤에 이어진 버그 수정 PR 하나를 정리했습니다.
라이브러리에 이슈가 나더라도 이를 관리하지 않고 General 한에러가 노출되던 경로를 어떻게 라이브러리 범위 안으로 관리하도록 수정한지에 대한 이야기입니다. 특히 아래 이야기에 좀 더 집중했습니다.
- "정확히 일치하는 예외 핸들러만 보던" 첫 구현이 왜 프레임워크와 어긋났는지, 리뷰에서 받은 MRO 기반 디스패치 제안을 어떻게 적용했는지, 그리고 그 제안을 글자 그대로 쓰지 않고 FastAPI의 내부 구조인 Starlette의 기본 미들웨어 동작까지 들여다보며 살펴본 내용을 함께 적었습니다.
- 아울러 오너의 리뷰 제안일수록 승낙하고 그대로 복사하고 싶어지지만, 프레임워크가 실제로 어떻게 동작하는지 소스로 확인하고 한 겹 더 파는 것까지가 리뷰 적용이라고 느꼈던 과정을 썼습니다.
>> 링크 클릭하기 <<
감사합니다.