사용중인 오픈소스의 버그 수정하기

들어가며

안녕하세요. 노머스에서 백엔드 개발을 하고 있는 JetBrains을 좋아하는 유영기입니다.

특별히 JetBrains 언급한 이유는 이번에 기여하게된 https://github.com/pinojs/pino-http/pull/288 와 깊은 관련이 있습니다.
사용중인 오픈소스 라이브러리에서 기대와 다른 동작을 할 때, WebStorm(JetBrains)을 통해 node_modules 탐험하기 좋습니다.
(다른 IDE도 Debug 기능이 없는 것은 아니지만, break를 잡기까지 환경설정에 많은 시간을 써야 합니다.)

입사 초 온보딩 시기

노머스는 Serverless + NestJS + TypeORM 등의 기술 스택을 기반으로 개발하고 있습니다.
그래서 입사 초반에 NestJS 관련 사용중인 여러 오픈소스 라이브러리를 살펴보게 되었고, 그중 에러와 로그 관련 패키지를 보던 중에, nestjs-pino의 이름이 적절하지 않다고 생각했습니다.
nestjs-pino는 pino를 바로 연결하는 것이 아니라, pino-http를 nestjs module로 만든 것이라, nestjs-pino 보다는 nestjs-pino-http가 더 적합해 보였습니다.

https://www.npmjs.com/package/nestjs-pino 에서도 아래와 같이 설치 가이드 하고 있습니다.

npm i nestjs-pino pino-http

버그 발견

@Module({
  imports: [
    ...
    LoggerModule.forRoot({
      pinoHttp: {
        customProps: (req, res) => ({
          context: 'HTTP',
        }),
      },
    }),
    ...
  ],
  ...
})
export class AppModule {}

nestjs-pino의 본체가 pino-http라는 취지로 위와 같이 customProps를 추가하였더니, context가 반복되는 상황이 발생하였습니다.

그리고, 구글링을 해본 결과 https://github.com/pinojs/pino-http/issues/216, 1년 이상된 오래된 이슈로 여러 사람이 문제가 발생한다고 이슈만 제기하고 있는 상태였습니다.

심지어, maintainer도 고치지 않고 있는 상황이었습니다.

버그 수정

pino-http repository의 example.js 예제 코드를 약간 수정하여, 바로 재현할 수 있었습니다.

---

이슈 수정 전 코드에서 2번째 customProps을 삽입하려는 시점에 break 잡은 장면입니다.

이 부분을 여러번 실행하면서 관찰하였습니다.

meta적으로 해결해 보려는 시도를 먼저 하였는데, pino-http 구조상 어려웠고,
이슈의 핵심적인 내용은 context 값을 meta로 가지고 있지 않고, req, res 각각 바로 stringify하여, chindingsSym property에 저장해 놓기 때문에 발생하였습니다.
2번째 customProps을 추가하려는 시점에 chindingsSym에 customProps가 들어있는지 체크하여 문제를 해결하였습니다.

https://github.com/pinojs/pino-http/pull/288/files

테스트 작성

그렇게 이슈는 수정하였지만, 반응이 바로 있지는 않았습니다.
하지만, 여러 개발자의 필요는 있었는지, PR에 와서, 엄지척 하는 사람도 있고,

추가로 github issue에 이슈 수정을 호소 하는 분도 있었습니다.

---

잊고 지내고 있었는데, 1달 반쯤 지났을 무렵 maintainer의 요청이 있었습니다.

이 때는 BEST fromm FRIEND 라는 회사 프로젝트가 한창 진행중일 때라, 심적 여유가 없었습니다.

무탈하게 프로젝트를 잘 마무리 하고, 어느 날 밤 이 이슈가 생각나 남은 테스트 코드도 작성하였습니다.

모든 테스트 코드는 stream을 기반으로 'data' 이벤트에서 데이타를 검증하는 방식으로 구현되어 있었습니다.
그 동안 이슈가 나오지 않은 이유는 항상 JSON.parse를 동반한 상태의 stream을 가지고 테스트 했기 때문이었습니다.
(JSON.parse에서 동일한 key가 있다면, overwrite 하기 때문에, 같은 key가 2개 존재하지 않는 결과를 가지게 됩니다.)
테스트 코드 분석은 이슈 해결과정 못지 않게 오래 살펴 보아야 했지만, JSON.parse 없는 stream을 생각해 내고, 코드는 바로 작성하였습니다.

테스트 코드까지 작성하고, Request Changes에 추가로 한분 더 reviewer로 참여 하셨는데,
재 요청한 코드 리뷰에서는 하루를 넘기지 않고, 리뷰해 주셨습니다.

이 PR은 v8.4.0로 릴리즈 되었습니다.

수정 이력

마치며

아무래도 조직의 구성원으로서 진행하고 있는 프로젝트가 우선시되지만, 사용중인 오픈소스에 이상한 점을 발견 했을 때, 지나치지 마시고 여유 있는 시간에 참여해 보세요!
특히, Debugger를 통해, 평소 익숙하지 않은 코드를 분석(read)할 때는 물론, 익숙한 코드의 개발(write) 속도 측면에서도 매우 유용합니다. IDE에서 Debugger를 Enable 해보시죠!

이렇게 또 하나의 로그(오픈소스 커밋, 블로그)가 쌓여져 갑니다.