I am trying to import my grist document onto another hosted server but I am getting this issue where there is no metadata?
The recovery mode also doesn’t seem to work either.
Hi @Tazwar_Belal.
Are you able to import the file from where you exported it? Checking if round-tripping the file works will help narrow down the problem.
George
Yes I can import the file from the server that I exported from.
Do you know what versions of Grist are running on both servers? Is the server you’re getting the errors in on an older version than where you exported?
George
The hosted service with the error is basically the Aws omnibus while the server that I exported the document from is a docker ran. But I was able to make imports onto the omnibus with the same document but it was 20-30 Mb smaller. This document is around 240 MB as a .grist file.
You didn’t mention where the 240 MB file came from. Was that from another Grist instance? Grist documents have Grist metadata, but if you construct a SQLite file yourself, it wouldn’t have Grist metadata and would show this error.
Another possibility, if the big file is a Grist document, is that it never actually got uploaded to its destination, i.e. that it got an entry in the database, but no file in the filesystem. In this case when you tried to open it, an empty SQLite file would’ve gotten created, and this would probably be the symptom.
As far as versions, those should all be compatible across Grist versions and installations, so I suggest looking for any errors during the upload process.
So this is an SQLite file and it is from another instance. I can import it onto the Grist page that you have got but not on the Omnibus. I was able to import these documents before which is strange.
Another important detail is that even when exporting a created file from the omnibus server I can’t upload that back in. I am thinking if this is because I have got S3 working which caused me to change up some variables in the DOCKER_CMD in the rc.local file to allow the snapshots to work.
There could be an issue specific to S3 and omnibus. Do you have logs from the time of upload? Do you see the file in S3, and does it have the right size?
Would we have to establish redis since it does seem to mention that right before the error?
That could be the issue if the file on S3 does exist.
There was a recent improvement to stop requiring Redis for this purpose (https://github.com/gristlabs/grist-core/pull/1098), so it may also matter whether you are using a release that includes this change (v1.1.16 or later).
Hi @dmitry-grist, the Grist version is 1.1.17 that Tazwar and I are using.
With S3 enabled we can export document but not import. With S3 disabled in params file, we can export and import just fine.
The log snippet shared earlier has the messages from when the document was opened. Are you able to collect logs from when the document is being imported?
@dmitry-grist, here is docker logs when document being imported when S3 is enabled.
DockerLogS3Enabled_20240819.txt (55.5 KB)
@Rohan how does the document stored in minio bucket gristbucket01 at key docs/6GqbC1ujv1DK2TCtx58b43.grist look? Is it a valid document that you can import into a known-good installation? Or does it look truncated?
If importing of a large document consistently didn’t work, I’d want to check the reverse proxy settings, but given that it works when s3 is disabled, that should be irrelevant.
Some related threads in github:
- Impossible to import grist file when using Minio storage · Issue #544 · gristlabs/grist-core · GitHub
- Error: ActiveDoc Failed to load document · Issue #467 · gristlabs/grist-core · GitHub
Both mention redis, although inconclusively. I’m not sure if anyone has checked whether s3 snapshots work without redis, although as @dmitry-grist mentioned there was a contributed change to eliminate a particular redis check. @Florent_F do you happen to know if s3 snapshots with minio have been tested without redis?
I have always tested Minio with Redis, even in some testing environment. I remember having encountered problem if Redis was not used (but I don’t remember the details).
1 Like
Guess it has to do something with this part of the log:
@dmitry-grist I think you mentioned that omnibus has not been worked on as much compared to the core version of grist so my guess is that we need to create a variable for REDIS_URL with the “redis://hostname/N”. The database number is different from the doc_Id being imported so I guess making that N equal the value shown on the log may do something.