좋습니다. 이제 에러를 없애고 재현하는 데 성공했습니다.
요약 (TL;DR)
- 이전에 정상적으로 작동했던 S3 설정으로 돌아가고 DiscoTOC 구성 요소를 삭제한 후 다시 설치하면, 에러 없이 구성 요소가 설치됩니다.
app.yml의 모든 S3 지시문을 주석 처리하여 S3를 비활성화하면, 구성 요소를 설치할 때 에러가 다시 발생하며, 업데이트 시에도 에러가 재발할 것으로 추정됩니다.DISCOURSE_USE_S3: false를 설정해도 Discourse가 S3 경로를 사용하는 것을 막지 못합니다. 이는 버그이거나, 이 설정이 제가 생각하는 것과 다른 기능을 하는 것 같습니다.
상세 설명
처음에 제가 한 일은 minio 설정을 다시 활성화하고, app.yml의 설정 옵션을 주석 해제한 후 앱을 재빌드하고 s3:upload_assets 태스크를 실행하는 것이었습니다. 사이트가 다시 올라간 후 구성 요소 섹션으로 이동했습니다. 이미 설치된 DiscoTOC 구성 요소는 여전히 에러를 표시했지만, 이를 삭제하고 다시 설치했을 때는 에러가 다시 나타나지 않았습니다. DiscoTOC 구성 요소 설치 과정에서 _sprite.svg_가 제 S3 서버에서 요청되었습니다.
문제를 재현하기 위해 시도하는 동안 흥미로운 문제를 겪었습니다. app.yml의 모든 S3 지시문을 활성화한 상태(즉, 주석 처리되지 않은 상태)로 두되 ``DISCOURSE_USE_S3: false```로 설정하면, minio가 실행 중이지 않으면 사이트 프론트엔드가 로드되지 않는 것 같습니다.
아마도 DISCOURSE_USE_S3: False는 모든 S3 접근을 비활성화하기 위한 것이 아닐 수 있습니다. 이름 때문에 그렇게 추정했지만, 분명히 그렇지 않습니다. minio 서비스를 다시 시작하고 프론트엔드를 새로고침하면 모든 것이 정상적으로 작동합니다. 이 상태에서는 에러를 재현하지 않고도 DiscoTOC 구성 요소를 제거하고 설치할 수 있습니다. 이는 적어도 잠재적으로 하나의 버그로 보입니다.
재현 가능한 에러로 이끈 세 번째 상태는 다음과 같습니다.
minio가 실행되지 않는 상태에서도 사이트가 다시 작동하도록 하기 위해, 설정에서 S3와 관련된 모든 항목을 주석 처리했습니다. 그런 다음 앱을 재빌드했고, 이제 minio가 실행되지 않아도 프론트엔드가 문제없이 로드됩니다. 그러나 DiscoTOC 구성 요소를 제거하고 다시 설치하면 에러가 다시 나타납니다. 이 상태에서 minio만 시작해도 재설치 시 에러가 다시 나타났습니다. app.yml 어디에도 S3 지시문이 설정되어 있지 않아, 백그라운드에서 S3에 접근을 시도하더라도 작동하는 설정 대신 기본값을 사용하여 시도하기 때문일 가능성이 높습니다. 그러나 posts:rebake를 실행한 후에도 일부 이미지가 여전히 S3에서 서빙되도록 시도하는 것 같습니다. (예: 1531a70abda0d81d1a4039b6f3fa38bea79ef0de_2_180x180.png/xl.meta)