I found a post about this from 2 years ago, but there was not a solution so apologies for duplication. I’m trying to upload a protocol to Fresco and I keep getting the same error:
Asset “ae9b7450-7076-11ef-a505-939c1a70c88c.jpg” was not found in asset folder!
The protocol doesn’t have any external images loaded into it, so I’m not sure how to address the bug. I’ve been successful at uploading other protocols and administering them. Thanks!
Hi Michael,
Welcome to the community! Really sorry about the upload issues you’re having. Will you please let me know the version of Fresco you’re currently using? You can find this on the Settings page.
If you’re able to share your protocol with me, that would also be helpful to troubleshoot this. You can email it to me at [email protected].
Thanks,
Caden
Hi Caden,
I’m running Fresco v1.2.2 (7b10a0a). It looks like I need to do a version update, so I will also do that and see if it resolves the issue. I sent you the protocol directly so let me know if that seems to be the source of the problem.
Hi Michael!
I know Caden has been chatting with you via email and has manually edited the protocol so that it works. I just wanted to post a quick update incase anyone else encountered this.
It looks like there might a small bug in Architect with removing protocol assets, whereby the asset file itself is correctly deleted, but the pointer to it is left behind. Interviewer didn’t actually verify that assets listed in the protocol were physically present, so this is actually only coming to our attention now because of improvements we made in Fresco.
From what we can tell, this is totally harmless, except that it of course prevented you from getting on with your work in this instance (and again, apologies for that). While we work on finding the cause of the issue in Architect, if people want to manually fix their protocols they can follow these steps:
This should allow the upload to complete.
Hi, I am having a different problem uploading protocols to Fresco. I keep getting an error message that prevents me from uploading most protocols I try. The debug information is below. I’ve been working with my University’s IT team to try to resolve the issue but we haven’t figured it out yet.
At first I thought it was perhaps because my protocol was large (1,300 KB) because I had previously successfully uploaded a smaller protocol (119 KB), but I even just cut out a looped instruction video I included which decreased my desired protocol’s size down to 91 KB and it still won’t upload.
Any suggestions are much appreciated!
{
“message”: “”,
“_tag”: “UploadThingError”,
“name”: “UploadThingError”,
“code”: “INTERNAL_SERVER_ERROR”,
“cause”: {
“message”: “”
}
Hi @cvb
Please can you confirm which version of Fresco you are using, and if you are still having this issue?
Hi Joshua,
Yes the problem is still happening. Same error message whenever I try to upload my protocol. I’m using Fresco v.1.1.0
Thanks!
Please upgrade to the latest version (2.1.0) following the instructions here: https://documentation.networkcanvas.com/en/fresco/deployment/upgrading#upgrade-process
Please note that as part of the upgrade you will need to get a new API key from the upload thing service. The app will provide links and information about how to do this when you log in to the dashboard after updating. Please let me know if you have any questions.
I am working with @cvb on this issue. We are trying to run this in an enterprise Kubernetes environment on premises, and I suspect that we are running into issues with a data center firewall. We have http(s) proxies available, but I cannot seem to figure out how to make that work with Fresco. Is this supported, and if so can you tell me how to configure it?
For what it is worth, when we import a protocol the file upload seems to work (files show up in UT) but then we get an error: “Failed to register metadata,”
Thanks!
Hi Alan - oh cool! Its great to hear about someone using the app in such an advanced deployment context.
Your setup isn’t something that I have personally tested, or have any real experience with, but I’ll try and help.
The symptoms you are describing sound to me like the “callback” from the UT service to the app is failing, which would imply a firewall or routing issue of some kind (assuming that the PUBLIC_URL variable has been set correctly). You’ll need to add rules or routing to allow the UT service to post to the webhook at env.PUBLIC_URL/api/uploadthing. I suppose the most likely candidate is that your setup is allowing outbound HTTP(s) traffic only. Could that be the issue?
@Joshua I am able to reach that callback URL from a machine on the public internet, so I think that inbound traffic is fine. Any way to allow me to set values for http-proxy, https-proxy, and noproxy when deploying? As I said, I have tried multiple ways to set environment variables but I do not think that the application is picking that up.
@alwalsh - I believe the variables you mentioned influence the docker daemon itself - not the application. The application simply binds to the docker network you specify. So in that sense, the app won’t pick up those changes - it should just use them automatically.
The complete dockerfile for generating the image is here: Fresco/Dockerfile at main · complexdatacollective/Fresco · GitHub
There is really nothing to it. We don’t do anything custom or unusual. NextJS creates a simple node HTTP server that runs on port 3000. It has no additional configuration.
The only environment variable you need to set specifically for a docker deployment is PUBLIC_URL.
Taking kubernetes out of the equation, does the app function correctly with the basic docker command:
docker run --env-file .env -p 443:3000 ghcr.io/complexdatacollective/fresco:latest
?
Thanks @Joshua . The Docker deployment works just fine on my laptop, but I believe that is simply because I do not have the firewall issue.
I turned on verbose logging and I see this:
{"message":"Fiber terminated with an unhandled error","logLevel":"DEBUG","timestamp":"2025-01-29T19:56:31.216Z","cause":"RequestError: Transport error (POST https://sea1.ingest.uploadthing.com/route-metadata)\n at catch (/app/.next/server/chunks/5587.js:1 │
│ :5407)\n at /app/.next/server/chunks/5587.js:8:58836\n at http.client POST\n at http.server POST {\n [cause]: TypeError: fetch failed\n at node:internal/deps/undici/undici:13484:13\n at process.processTicksAndRejections (node:internal/pro │
│ cess/task_queues:105:5) {\n [cause]: ConnectTimeoutError: Connect Timeout Error (attempted addresses: 35.81.66.139:443, 52.27.0.41:443, timeout: 10000ms)\n at onConnectTimeout (node:internal/deps/undici/undici:2602:28)\n at Immediate._onImme │
│ diate (node:internal/deps/undici/undici:2583:11)\n at process.processImmediate (node:internal/timers:491:21)\n at process.callbackTrampoline (node:internal/async_hooks:130:17)\n }\n}","annotations":{},"spans":{"handleUploadAction":10585},"fibe │
│ rId":"#26"}
Is that an issue connecting to UT?
It looks to me like this is the pertinent part:
Connect Timeout Error (attempted addresses: 35.81.66.139:443, 52.27.0.41:443
These look like they are failed outbound connections, presumably to the UploadThing service. My only advice is to try to create an isolated instance of your cluster with the firewall disabled to further isolate the issue.
At this point I don’t think I am able to assist much further, I’m afraid. I think we can safely say that this isn’t an issue with the app, and that no configuration changes are needed on our side. If that turns out not to be the case, and we need to implement some changes, please let me know and I will make a plan to assist you.
@Joshua One more question related to this thread: does the export interview function send zip files to UploadThing or does the file get saved someplace else?
Hi @alwalsh
The export function stores the zip file in upload thing until it has been downloaded, at which point it is deleted. If there is an error during the export, the file is also deleted.