Grist+MinIO self-hosted : document originating from template : snaphots unavailable #1453
Comments
|
Some hours later, one of the concerned docs starts showing snapshots. Maybe my manual fiddling with |
|
Hmm none of this rings a bell @raph-topo. Do you happen to know if these problems existed for you prior to 1.4.0 or is that the first version you tried? |
The |
|
Just tried running Grist locally with minio+redis and things feel normal? Tried replicating B but things worked for me. The description of B sounds almost like an auth problem. Also the |
|
The issue existed with 1.3.3 as well. I did not use earlier versions. Well Redis is being populated a lot with all kinds of keys with grist docs uuids. In this sort of "manually-fixed" doc, upon replacing a doc from a snapshot: And from then on all snapshots have disappeared, and Document History > Snapshots shows: "Snapshots are unavailable. Only owners have access to snapshots for documents with access rules." ❌ MinIO Object Browser > Hmm, upon a restart of all containers (Grist now with version 1.4.2), snaphots do show up for that one "manually-fixed" doc from scenario C & The issue does persist as scenario B still results in ❌ |
|
Trying with Redis removed from the stack results in this when editing the doc ❌ Still that on some other docs as well, including those that did not have an issue before. Re-enabling Redis does not fix it. |
|
Something odd about this. @fflorent @georgegevoian @Spoffy are any of these symptoms familiar? The only thing that catches my eye is |
|
Yes, I redacted with docId or … Indeed, the As mentioned, I did set the empty string Maybe some parts of the code accept an empty prefix, others not? I tried setting I do confirm that update+restart Grist container fixes some docs, but restart at same version does not. Does that help pinpoint? |
Hi @raph-topo.
|
|
Yes, I do get But the extra path does not appear in MinIO, working docs still get snapshots, and non-working still don't. Ah, upon creating a new doc, the path appears in MinIO and scenario B & C are fixed! |
|
Is Redis caching MinIO access paths? I thought Grist was loading docs from MinIO, but all content etc. does continue to appear despite the change in paths. |
|
Okay so we have found the issue (empty |
That's the reason indeed: Grist does not support empty Unsetting and moving all objects in MinIO into Two options from here:
|
|
I tried to reproduce your issue by using this Which is probably quite similar to the environment where the bug has been observed. And applying the below patch: diff --git a/docker-compose-examples/grist-with-postgres-redis-minio/docker-compose.yml b/docker-compose-examples/grist-with-postgres-redis-minio/docker-compose.yml
index 1202fd27..57182855 100644
--- a/docker-compose-examples/grist-with-postgres-redis-minio/docker-compose.yml
+++ b/docker-compose-examples/grist-with-postgres-redis-minio/docker-compose.yml
@@ -21,6 +21,7 @@ services:
GRIST_DOCS_MINIO_BUCKET: grist-docs
GRIST_DOCS_MINIO_ENDPOINT: grist-minio
GRIST_DOCS_MINIO_PORT: 9000
+ GRIST_DOCS_MINIO_PREFIX: ""
volumes:
# Where to store persistent data, such as documents.
@@ -49,6 +50,8 @@ services:
grist-minio:
image: minio/minio:latest
+ ports:
+ - 9001:9001
environment:
MINIO_ROOT_USER: grist
MINIO_ROOT_PASSWORD: ${MINIO_PASSWORD}(the ports for From what I have seen so far, everything works as expected. But I must have missed details in the above conversation, I miss time for today, I need to read it carefully a bit later. If in the meantime @raph-topo you successfully reproduce the issue with this docker-compose example, please let us know, it would be really helpful for us to investigate and bring a fix. And thank you for the report BTW! |
|
FYI, I could reproduce the issue with the above patch, that's indeed surprising 👀 |
|
@fflorent thanks for looking into this. I haven't had a chance to look closely myself, but the first thing I'd be checking is if a prefix set explicitly to |
Great, so we are certain about the origin. Some more experiments absent empty empty string no ending slash |
Describe the current behavior
Hi!
Thanks for this incredible tool!
Steps to reproduce
A
/_docId_.gristfile with multiple versions ✅/assets/unversioned/_docId_/meta.jsonexists ✅B
/_docId_.gristfile with multiple versions ✅/assets/unversioned/_docId_/meta.jsondoes not exist ❌C
Unexpected error > can't access property "callback", t is nullUnexpected error > operation failed to become consistent: versions - 1,not ready,3005,not ready,8111,not ready,16792,not ready/_docId_.gristfile with multiple versions ✅/assets/unversioned/_docId_/meta.jsondoes not exist ❌Tried the following on an imported document, but none starts snapshotting :
/assets/unversioned/_docId_/meta.json(content[]) : makes Document History > Snapshots stay indefinitely emptyDescribe the expected behavior
S3-based snapshotting should work on imported documents from the moment of importing.
According to https://community.getgrist.com/t/resynchronizing-snapshots-with-s3-versions/3220
meta.jsonshould be recreated on the fly? Does not happen. (Makes me notice/apiconsoleis missing the/api/docs/_docId_/snapshots/*endpoint.)Trying the same on https://docs.getgrist.com/ seems not to have this issue.
Where have you encountered this bug?
Instance information (when self-hosting only)
docker-compose.ymlredis:alpineminio/miniogristlabs/grist:latestsome env vars which might be relevant:Architecture: single-worker, Grist>MinIO/Redis over Docker default network, not proxied to internet
Admin Panel > Self Checks: all ✅
Browser name, version and platforms on which you could reproduce the bug: Edge, Firefox
Browser console log if relevant:
Server log if relevant:
When opening Document History > Snapshots, after ~ 10s elapsed:
At import & sometimes, when opening Document History > Snapshots, after ~ 10s elapsed:
The text was updated successfully, but these errors were encountered: