With Docker : Error Unexpected reading "/app/src/index.tsx"
Hello,
I use Convertx with Docker container.
I have the error : "Unexpected reading "/app/src/index.tsx" I clean my install, I download the latest image
and I build my docker compose but the error is always present
Regards
How does your docker-compose look?
networks:
...
services:
convertx:
image: ${IMAGE}:${VERSION:-latest}
container_name: convertx
networks:
- convertx-network
deploy:
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 30s
security_opt:
- no-new-privileges
ports:
- "17659:3000"
volumes:
- ./data:/app/data:rw
environment:
- ACCOUNT_REGISTRATION=${ACCOUNT_REGISTRATION}
- JWT_SECRET=${JWT_SECRET}
- HTTP_ALLOWED=${HTTP_ALLOWED}
labels:
- "com.centurylinklabs.watchtower.enable=true"
I have the same error on v0.12.0 No problem with v0.11.1
Weird that so many get it now, I am not able to reproduce it unfortunately
Could you maybe test the :main image? Doubt that it will help, but maybe something is currupt in the release?
I've got the same issue on upgrading to v0.12.0. Exactly the same logs as @xavier-GitHub76 . I'm Running out of Container Manager (docker) on a Synology DS-423+ No issues once I reverted back to v0.11.1.
My compose was:
convertx:
image: ghcr.io/c4illin/convertx
container_name: convertx
restart: unless-stopped
ports:
- 3005:3000
environment:
- JWT_SECRET=XXXXX # will use randomUUID() if unset
- PUID=XXXX
- PGID=XXXX
- ACCOUNT_REGISTRATION=false
- HTTP_ALLOWED=true
- ALLOW_UNAUTHENTICATED=true
- AUTO_DELETE_EVERY_N_HOURS=24
volumes:
- ./convertx:/app/data
networks:
- tunneling
depends_on:
- nginx
Maybe test docker run c4illin/convertx and see if it starts? I dont understand what could cause the issue
I try on another device with docker run
sudo docker run -d -e ACCOUNT_REGISTRATION=true -e JWT_SECRET=xxx -e HTTP_ALLOWED=true -p 3000:3000 -v :data --name convertx ghcr.io/c4illin/convertx
I have "SQLITE_CANTOPEN" error
"SQLITE_CANTOPEN" error is mentionned by https://github.com/C4illin/ConvertX/issues/236
with -v ./data:/app/data, it's OK
but without the error is present
@MuadDibVV @xavier-GitHub76 what cpu are you using? The other two with the same error both used a Synology DS with Intel Celeron J4125
My nas is a synology with Intel Celeron J4125. My second test is on a lenovo x250
I have an Intel Celeron J3455 (Synology 918+)
And I have the same error with the :main image
So it seems everybody with the same error is using similar CPUs, is these CPUs special in any way?
I think the culprit might be the upgrade from bun 1.2.2 to 1.2.4
I downgraded to 1.2.3, test the :main when you have time
Thank you, but i still have the problem with the :main image
Me too
Thanks for testing! Downgraded to 1.2.2 now, if that still doesn't work I am out of ideas unfortunately
Test :main again when you have time :)
It's OK 👍
That's great! Then we know what the error is. This should probably be reported to bun, anybody who wants to do that?
It's done :)
@xavier-GitHub76 could you test 1.2.5 that just was released?
I succeed to deploy my own docker container with bun 1.2.4 on my synology nas Details are here : https://github.com/oven-sh/bun/issues/18036
Hmmm then something is weird in ConvertX after all, do you have any idea?
No unfortunately
please ignore my lack of knowlege and just barging in, but trying to make this work i believe i found something of interest.
switching to the commonJS elysia (adding dist/cjs/index.js to the tsx file) made the file load without the error. according to some ai help: printVersions.ts is unreadable or has syntax issues. issue with bun handling imports.
"By default, when importing elysia, Bun resolved it to dist/bun/index.js. However, bun resolve elysia pointed to dist/cjs/index.js. This suggests that Bun's module resolution isn't fully consistent, especially with mixed ESM/CJS packages."
hope this helps you.
(same error on ds224+ (J4125))
I've made a PR at oven-sh/bun#18172 that may help with the error: Unexpected issue, but I'm not certain since I can't repro the error with ConvertX on my own machine. Curious if any of you could try to see if it helps? You can download bun-linux-x64-musl-baseline.zip from the "Artifacts" tab on our CI, extract it, and then try replacing the Bun executable in the container with the one from that PR and see if you still get any errors.
That PR is merged now so you can also try using the canary-alpine tag on our Docker image, instead of manually replacing the Bun binary.
Thanks for the help and fix! :)
Oh, you were able to test and see that canary fixed the issue?