Edge Router is Traefik instead of Caddy (Company Policy, see below)
Describe the Problem/Error/Question:
Although I’d rather have Excalidraw back as the whiteboard plugin, I tried to upgrade Tldraw to the current version. I’m currently preparing our upgrade path from 6.0, and installed an empty vanilla 6.2. version as a reference point. No data, minimal changes to the configuration where needed.
Only thing not working so far:
In Tldraw, I cannot create a new whiteboard. The name is created in the list, but the circle animation keeps spinning. When I revisit this whiteboard, the same happens again.
I can, however, draw on existing canvasses without a problem
Since I started with an empty server, you might ask why I have existing drawings
I ran the same setup, and just exchanged Tldraw with version 2.1.1 (worker and plugin)
I this setup, I can create drawings, update them, erase them.
Plugin 2.6.0 against worker 2.1.1 also works. The interface does not deliver (empty icons), but I can create drawings / whiteboards blindly.
As soon as worker 2.6.0 runs, I receive the bug as described above.
Yes, I need to run Treafik instead of Caddy as my edge router, but thus far, I was quite successful in replicating all Caddy settings, as the working 2.1.1 version proves.
Therefore my question: Does 2.6.0 has some new behaviour I need to address? Specifics below:
Error messages:
When I try to create a new whiteboard, the browser network log shows a constant endless switch between
Successful GET to /api/v2.1/workspace/1/dtable/Unbenannte%20Base/temp-api-token/ (api_token is returned)
and
Call to the worker with /connect/someID, using the API token, which is the upgraded to a websocket connection
The websocket connection is then stopped, and another attempt is started.
Background from the worker logs: The worker basically fails to create the room data in the base’s data storage, and subsequently cannot retrieve it. Something in my (Traefik?) setup prevents this.
Does that ring a bell for anyone? What could possibly go wrong when the worker tries to create the room (data) for the first time, but editing existing ones causes no problems?
As it seem, this does not prevent me from updating, because 2.1.1 still works.
sorry for the inconvenience! I have a few thoughts/questions:
From version 2.3.0 onwards, the plugin tries to load icons/assets from the worker instead of the public tldraw CDN, so this is expected if you use an older worker image.
Can you share the (redacted) log entries from the worker container?
And did you test a previous version of the worker image? (e.g. 2.3.0, the default for SeaTable v6.1 installations)?
@sha before I start barking up the wrong tree, I started running a clean Seatable install out of the box, including caddy. That didn’t work either.
I don’t want to bother you with anything that might be entirely my fault, so I’ll try one more totally clean install from scratch, and see what happens.
if that doesn’t help, I’ll use older versions and / provide error logs.
Thanks for the detailed report. The worker logs pinpointed the issue immediately.
The issue
SeaTable 6.2 changed the error it returns when a drawing has no saved content yet, and the worker no longer recognized it as “this is a new drawing”. So new drawings never got created, while existing ones kept working.
I am sorry that I did not detect this during our testing with SeaTable 6.2.
How to fix
I have created a new docker container with tag 2.6.1 (seatable/tldraw-worker - Docker Image). This container fix the issue. No plugin re-install needed.
Would be great if you could confirm it works on your setup.
@cdb THANKS! I can confirm that it works now as intended. I can also confirm that it works with my tweaked version of the plugin (setting the WORKER_URL to window.dtable?.server + ':443' + '/tldraw') and the worker container on https://my-server.domain/tldraw instead of Port 6239.
Thanks for checking this proactively, even while I was still struggling to verify my findings against the customized versions I need run to comply with internal rules for Docker networks, use of Traefik, an internal CA and ACME server, and the restriction of only ports 443 and 80 open on our servers and firewalls.
As a learning from this, I now have a platform where I can easily run a vanilla test system almost straight from your “releases” github, with minimal tweaks. Should be easier in the future now to verify suspected bugs.
Which brings me to the reason why I’m describing this in such detail:
As a minimal learning for you, could you make the /opt part for the local storage of volumes at least partly customizable in your compose files? I’m thinking of something like this:
volumes:
# new variable #1
- "${SEATABLE_DATA_DIR:-/opt}/seatable-server:/shared"
# new variable #2
- ${SEATABLE_CONFIG_DIR:-./config}/seatable-nginx.conf:/etc/nginx/sites-enabled/default
- type: bind
# new variable #3
source: "${SEATABLE_LICENSE_DIR:-./}seatable-license.txt"
target: "/shared/seatable/seatable-license.txt"
read_only: ${SEATABLE_LICENSE_FORCE_READ_ONLY:-false}
bind:
create_host_path: false
Maybe there are other users like me who don’t get access to /opt with their docker users for security reasons, or even run rootless docker to the same effect. Also, they might run Seatable not with a local docker compose, but from systems like Komodo or Portainer. This minimal tweak would save us from creating override files for just this single purpose.
Do it like thousands of other people who have used SeaTable to develop powerful processes and get their ideas and tasks done more efficiently.
