Troubleshooting

DRF를 활용하여 JWT 인증을 구현하다 마주한 문제 상황이다. 우선 로그인 기능을 다음과 같이 구현했다.post method로 api 호출할 때 에러 메세지로 Expected a string value 라는 문구가 콘솔창에 찍혔다. TokenObtainPairSeri

Django 프로젝트 진행 중, 파이참으로 가상 환경 생성하는 것이 아닌 명령어로 생성한 가상환경을 파이참에 연결할 때 발생한 에러임. 인터프리터를 추가하기 위해 우측 하단에서 인터프리터를 추가를함 기존에 만들어둔 가상환경을 인터프리터로 연결할것이기 때문에, Exi

프로젝트 대략적인 구조를 보면 backend 프로젝트 하위에 config라는 이름의 프로젝트 루트 디렉토리가 있다. 해당 디렉토리에 모든 앱에서 사용할 공통 예외처리를 exceptions.py라는 모듈에서 관리 중이다. exceptions.py 모듈을 사용하기 위해,

문제 상황 개발 중 대량의 데이터가 적재된 파일들을 읽어서 찾고자 하는 키워드가 포함된 라인 수를 세는 로직을 개발하게 됐다. 하나의 파일에는 대략 3천만 ~ 5천만 라인의 데이터가 있어 하나의 파일을 읽어드리는데도 약 20초의 시간이 소요됐다. 하지만 이러한 파일들

macOS 환경에서 docker를 사용하여 컨테이너를 띄우는 상황에서 'Operation not permitted' 에러를 마주쳤다. 처음엔 단순하게 파일의 권한이나 소유권 문제라고 생각하여 이러한 것들을 변경했지만 해결되지 않았다. 찾아본 결과 macOS 환경에서

RDS를 사용해 PostgreSQL 데이터베이스를 생성 후, 로컬 터미널을 통해 접속을 하려고 하는데 연결 관련 문제가 발생했다. 이전에 작성한 글과 다양한 블로그 글을 참고하여 RDS를 새롭게 생성해도 해결되지 않았다. 다양한 글을 찾아봤을 때 Connection

제목과 동일하게 Github Actions 워크플로 실행 중에 'rsync: [generator] delete_file' 에러가 발생했다. 정확한 에러를 살펴보면 다음과 같다. rsync: [generator] delete_file: unlink(backend/log

상황 올바른 계정을 사용하여 로그인하는 상황에 대한 serializer의 단위 테스트를 작성하던 중 마주한 문제이다. serializer는 아래와 같이 구성돼있다. [accout/serializers.py] class UserLoginSerializer(seria

WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v3) and no specific platform was requeste

상황 drf로 api 서버를 만들고 배포했다. 회원 정보를 어드민 페이지로 관리하기 위해 어드민 개발도 진행했다. 배포 후 어드민 페이지에 접근을 했는데 아래와 같은 에러가 발생했다. CSRF란? Cross-Site Request Forgery(사이트 간 요청 위

상황 실시간 서비스를 운영하는 상황에서 인증번호 번호 요청은 성공했지만 이메일을 확인해도 인증번호 관련 메일이 없다는 사용자의 제보를 받았다. 해결 방법 상황1 서버의 Redis 컨테이너 로그를 확인하던 중 아래의 에러를 발견했다. Traceback (most re

고객 예약 생성과 같이 복잡한 로직을 구현 중에 템플릿 메소드 패턴과 전략 패턴 등의 디자인 패턴을 적용하고 있었다. 전략 패턴을 위해 구현한 추상 클래스에서 예약 관련 비즈니스 로직을 구현한 클래스와 서로 import를 하도록 구현하여 발생한 문제였다. 로직이 길고

상황 운영 중인 서비스에 새로운 기능을 추가로 개발하면서 데이터베이스 구조가 굉장히 많이 변경됐다. 데이터의 양이 많지 않은 상황이라 새로운 데이터베이스에 기존 데이터를 마이그레이션하고 추가적인 필드를 직접 추가하는 방식으로 진행하는 것이 간편할 것이라고 판단했다. 파

처음으로 서비스를 올리고 동일한 상황을 맞닥드린 적이 있다. 동일한 에러가 발생한 것 보니 그 당시 취한 조치가 적합하지 않았던 것 같다. 당시에는 프리티어의 ec2 인스턴스의 메모리 문제라고 생각하여 overcommit 설정을 했고, 이후 동일한 에러가 발생하지 않았