Ikjo's Technology blog

콜백 안에 또 다른 콜백 spring webflux 에서 제공하는 WebClient 를 기반으로 3rd party server 와 통신하면서 retry 처리를 해줘야 할 일이 있었다. 여기서 말하는 retry 처리란 아래와 같았다. 1. our server 는 target server 에 요청 시 access token 을 함께 전송한다. 2. target server 는 our server 의 요청을 처리하기 전 access token 이 유효한지 검증한다. 3. (access token 이 만료된 경우) target server 는 our server 에 access token 이 만료되었다고 응답한다. 4. (해당 응답을 받은) our server 는 target server 에 새로운 access..

발생 이슈 입사한지 2달 정도 됐을 당시 주어진 Task 를 진행하는 중에 기존 코드 상 트랜잭션 애노테이션이 붙어있음에도 불구하고 JPA 영속성 컨텍스트에서 제공하는 Dirty check 기능이 활성화되지 않고 있었던 이슈가 있었다. 이로 인해 update 쿼리가 나가야할 때 나가지 않는 문제가 있었다. 코드의 상황은 대략적으로 아래와 같았다. @Slf4j public class TokenManager { @Transactional public void updateToken() { try { Token token = externalApiTokenRepository.find().orElseThrow(); token.update(); } catch (Exception e) { log.error(".... ..

발생 이슈 gRPC(google Remote Procedure Call) 를 통해 요청을 받은 후 spring-data-jpa 에서 제공하는 SimpleJpaRepository 의 save 메서드를 호출하는 시점에 아래와 같은 에러가 발생했다. java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and ..

발생 이슈 지난 달 다른 서비스 팀의 친한 백엔드 개발자로부터 원인을 알 수 없는 이상한(?) 현상이 나타나고 있다는 것을 전해 듣고 해당 팀에 가서 어떤 이상한 현상인지 보러갔다. 해당 이슈는 동일한 조회 쿼리를 사용했음에도 불구하고 로컬 환경에서는 데이터 정렬이 정상적으로 처리되어 조회되는데, 개발 서버 환경에서는 데이터 정렬이 비정상적으로 처리되어 조회된다는 것이었다. 👀 쿼리 분석 우선, 그 조회 쿼리가 무엇인지 살펴보았다. 해당 쿼리의 형태는 대략적으로 다음과 같았다. WITH temp_a_tbable AS ( SELECT ... FROM a_table WHERE deleted_at IS NULL ), temp_b_table AS ( SELECT ... FROM b_table WHERE dele..

발생 이슈입사한지 얼마 안되 배정받았던 소소한(?) 이슈가 있었다. FE 측에서 BE 측에 페이지네이션 기능을 포함한 목록 조회 API 를 호출했는데, 분명히 페이지네이션 관련 파라미터를 제대로 할당했음에도 불구하고 페이지네이션된 데이터가 아니라 전체 데이터가 조회된다는 것이었다. 👀  코드 분석당시 나는 우선적으로 해당 API 의 로직 중 데이터베이스에 접근하는 계층의 로직을 우선적으로 살펴보았다. 해당 로직을 살펴보니 엔티티 매니저 의존성을 직접 주입받고 이를 활용하여 데이터베이스에 접근하고있었으며, 네이티브 쿼리를 이용하고있었다. 이때 동적 검색 기능을 구현하기 위해 일일이 조건절을 만들어 문자열 쿼리를 만들어주고 있었다. 근데, 쿼리를 생성하는 로직을 아무리 살펴봐도 페이지네이션을 설정하는 부분..