ERR. Download aborted

Question

ERR. Download aborted

mostafaznv opened this issue 3 years ago · 27 comments

Hi, thanks for your great work.
I get this error and I don't know why it happens. any idea?

sudo figma-backup -e "EMAIL" -p "PASSWORD" -t "TOKEN" --projects-ids "ID" --download-timeout 45

> Starting the backup task...
> Authenticating the bot...
        . Bot successfully logged in.
	. Caching the cookies...
	. Looking for cached cookies...
	. Restoring the cached cookies...
> Backuping the file(Project Name)...
        . Setting the download behaviour...
	. Saving a local copy of the file(Project Name)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 2700s exceeded.
Backup task finished! (time elapsed: 2797s)

Answer 1 · 2022-02-25T08:23:54.000Z

@mostafaznv

ERR. Download aborted | Timeout of 2700s exceeded.

It seems that the download process has exceeded the given --download-timeout option.
Try to re-run the process using --debug option and check if that's the case.
If so, try to increase the amount of --download-timeout option. (you are probably facing a huge Figma file)

Please let me know if you resolved the issue.

Answer 2 · 2022-02-25T14:02:37.000Z

I have the same issue
seems like downloading doesn`t even starting, network activity is about null

Answer 3 · 2022-02-25T16:39:01.000Z

@Believemenot
Try to re-run the process using --debug option and please report me the situation.

Answer 4 · 2022-02-25T16:47:10.000Z

with --debug option I get this error:

Error: Failed to launch the browser process!
[168853:168853:0225/102648.561888:ERROR:browser_main_loop.cc(1409)] Unable to open X display.
[0225/102648.579050:ERROR:nacl_helper_linux.cc(307)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md

    at onClose (/usr/lib/node_modules/figma-backup/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:203:20)
    at Interface.<anonymous> (/usr/lib/node_modules/figma-backup/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:193:68)

I'm trying to find a workaround for this error but I don't know if it's about your package or my machine.

Answer 5 · 2022-02-25T16:54:48.000Z

When i run with --debug option but nothing dowloads

> Starting the backup task...
> Authenticating the bot...
        . Bot successfully logged in.
	. Caching the cookies...
	. Looking for cached cookies...
	. Restoring the cached cookies...
> Backuping the file(3D иконки)...
        . Setting the download behaviour...
	. Saving a local copy of the file(3D иконки)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        . File (3D иконки) successfully downloaded.
> Backuping the file(App Icon)...
        . Setting the download behaviour...
	. Saving a local copy of the file(App Icon)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        . File (App Icon) successfully downloaded.
> Backuping the file(App Mockups)...
        . Setting the download behaviour...
	. Saving a local copy of the file(App Mockups)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        . File (App Mockups) successfully downloaded.
> Backuping the file(Продавцы App)...
        . Setting the download behaviour...
	. Saving a local copy of the file(Продавцы App)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        . File (Продавцы App) successfully downloaded.
Backup task finished! (time elapsed: 116s)

Answer 6 · 2022-02-25T17:03:09.000Z

@mostafaznv

The error "Unable to open X display" is a known error on Linux machines and It's related to the Puppeteer (a package we are using for Bot purposes).

There's a workaround for this:
Stackoverflow
Puppeteer's Github

Answer 7 · 2022-02-25T17:05:37.000Z

@Believemenot

It seems that there's no problem with the Bot itself.
Can you also provide the full ActionLog of the process without --debug option?

Answer 8 · 2022-02-25T17:13:06.000Z

> Starting the backup task...
> Authenticating the bot...
        . Bot successfully logged in.
	. Caching the cookies...
	. Looking for cached cookies...
	. Restoring the cached cookies...
> Backuping the file(3D иконки)...
        . Setting the download behaviour...
	. Saving a local copy of the file(3D иконки)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 60s exceeded.
> Backuping the file(App Icon)...
        . Setting the download behaviour...
	. Saving a local copy of the file(App Icon)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 60s exceeded.
> Backuping the file(App Mockups)...
        . Setting the download behaviour...
	. Saving a local copy of the file(App Mockups)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 60s exceeded.
> Backuping the file(Продавцы App)...
        . Setting the download behaviour...
	. Saving a local copy of the file(Продавцы App)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 60s exceeded.
Backup task finished! (time elapsed: 366s)

Answer 9 · 2022-02-25T17:18:03.000Z

@mostafaznv

The error "Unable to open X display" is a known error on Linux machines and It's related to the Puppeteer (a package we are using for Bot purposes).

There's a workaround for this: Stackoverflow Puppeteer's Github

Thanks. I fixed that issue (with this workaround)
then I tried to run script with --debug option. this is the result:

> Starting the backup task...
> Authenticating the bot...
        . Bot successfully logged in.
	. Caching the cookies...
	. Looking for cached cookies...
	. Restoring the cached cookies...
> Backuping the file(Project Name)...
        . Setting the download behaviour...
	. Saving a local copy of the file(Project Name)...
	. Opening up the figma command pallete...
	. Typing down the download command...
	. Execute the download command...
        ERR. Download aborted | Timeout of 300s exceeded.
Backup task finished! (time elapsed: 384s)

it doesn't provide any extra information

more information:

my project is a simple project (file size is 300kb)
I tried to run script with two servers. Iran and Netherlands but result was the same.

Answer 10 · 2022-02-26T05:47:55.000Z

@mostafaznv

--debug runs the bot in headful mode which will open up a chromium and proceed each steps in the browser.
Couldn't you see the actions in a headful way?

Answer 11 · 2022-02-26T06:23:39.000Z

@mostafaznv

Unfortunately I can't reproduce the problem due to differences in the machines we are using.
All I can tell (based on the given error on the downloading process) is that your download process is taking too long. However, the problem might be something else.

Since your machine is preventing the bot to run a headful process (via --debug option) we can't investigate further, so I encourage you to do run the process with --debug option on:

1- Your machine (Not a VM) and monitor the process.
2- Another machine (preferably MacOS) and monitor the process.

You have to somehow get the bot to work headfully on your machine so you can monitor the process on the browser itself.
Please read the following docs for more information:
Puppeteer's Github
Puppeteer's Troubleshooting

Answer 12 · 2022-03-09T08:08:59.000Z

ERR. Download aborted | Timeout of 60s exceeded.

@Believemenot

Ok let me explain the process and the meaning of this error, so that you might figure out what you are doing wrong.

The bot fetches the given projects using Figma API and then navigates to each files of the fetched projects.
When the page of the Figma file loaded successfully the bot is going to open up the command palette and write down the command to download a copy of your file.

The download process doesn't give us any feedback to check whether it is done or not. To fix that problem we are checking the existence of an specific DOM Node through a listener. However, this listener has a timeout and when it exceeds the timeout its going to stop the downloading process of that specific file with the error ERR. Download aborted | Timeout of Xs exceeded.

So a workaround for this error is to give a bigger downloadTimeout value.

Answer 13 · 2022-09-14T13:44:29.000Z

Unfortunately, I know a little about Typescript, I try to explain what I did, I hope it helps we can find the root cause:

Build the image with the Dockerfile

FROM node:18.9-slim

RUN apt update && \
    apt install -y fonts-liberation libappindicator3-1 \
    libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 libcairo2 \
    libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 libgcc1 \
    libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 \
    libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 \
    libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release \
    gconf-service libgconf-2-4 libgdk-pixbuf2.0-0 \
    wget xdg-utils xvfb ca-certificates libappindicator1 && \
    rm -rf /var/lib/apt/lists/*

RUN npm install -g figma-backup
CMD ["figma-backup"]

with this command:

docker build -t figma -f Dockerfile .

Clone the repository:

git clone https://github.com/mimshins/figma-backup.git

Run the docker container with the volume:

docker run --name figma-backup -it  -v "${PWD}/figma-backup:/app" figma bash

Run the figma-backup command in the debug mode:

figma-backup -e "<YOUR_EMAIL>" -p "<YOUR_PASSWORD>" -t "<YOUR_ACCESS_TOKEN>" --projects-ids "ID1" "ID2" ... "IDx" --debug

give the following error:

Error: Failed to launch the browser process!
[19:19:0914/132053.471715:ERROR:browser_main_loop.cc(1409)] Unable to open X display.


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md

    at onClose (/usr/local/lib/node_modules/figma-backup/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:203:20)
    at ChildProcess.<anonymous> (/usr/local/lib/node_modules/figma-backup/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:194:79)
    at ChildProcess.emit (node:events:525:35)
    at ChildProcess._handle.onexit (node:internal/child_process:291:12)

I found a workaround (this):

Xvfb -ac :99 -screen 0 1280x1024x16 &
export DISPLAY=:99

Now it does not complain, it aborts with timeout though.

> Starting the backup task...
> Authenticating the bot...
        . Bot successfully logged in.
        . Caching the cookies...
        . Looking for cached cookies...
        . Restoring the cached cookies...
> Backuping the file(sample_project)...
        . Setting the download behaviour...
        . Saving a local copy of the file(sample_project)...
        . Opening up the figma command pallete...
        . Typing down the download command...
        . Execute the download command...
        ERR. Download aborted | Timeout of 300s exceeded.

To find if this is the case for all the docker containers, I wrote a simple script, download.js and copy it to the /app directory:

const puppeteer = require('puppeteer');
const path = require('path');
const downloadPath = path.resolve('/app');
async function simplefileDownload() {
    const browser = await puppeteer.launch({
        headless: false,
        args: ['--no-sandbox']
    });
    
    const page = await browser.newPage();
    await page.goto(
        'https://unsplash.com/photos/tn57JI3CewI', 
        { waitUntil: 'networkidle2' }
    );
    
    await page._client.send('Page.setDownloadBehavior', {
        behavior: 'allow',
        downloadPath: downloadPath 
    });
    await page.click('.mef9R ')
}
simplefileDownload();

Run node download.js would download but it stuck and did not exit. I think it is why we got timeout and the project might be downloaded and simply we do not know where it is placed.

Do you have any idea about that? and could we have an option to specify the downloadPath?

Answer 14 · 2022-09-14T19:26:00.000Z

@monegim

Do you have any idea about that? and could we have an option to specify the downloadPath?

The reason it gets stuck is that you can't exactly tell when the download process ends so you could close the page and terminate the puppeteer.
The same thing is going for Figma with a small difference. When we actually downloading files there will be a Snackbar (Toast) component showing the download progress.

await page.waitForFunction(
  () => !document.querySelector('[class*="visual_bell--shown"]'),
  { timeout: downloadTimeout }
);

Here I wait for that component to hide from the DOM Tree.
Note: I'll wait for the specified download-timeout option (defaults to 5m or 300s).

There might be an issue with Figma not showing this component to your machine. However, even if the download aborted due to timeout excess, it would've completely downloaded the file in the relative download path (if the file is small enough to be downloaded in that time).

Unfortunately puppeteer doesn't support specifying absolute download path.
It is relative to the directory which you ran the command.

In figma-backup I'm creating a directory called figma-backup-root relative to the working directory.
It's working fine both for MacOS and Windows, but unfortunately it has known issues for Linux.

This issue definitely needs further investigations on Linux Machines and Docker Containers.

Answer 15 · 2022-09-14T19:36:12.000Z

@monegim

Now it does not complain, it aborts with timeout though.

Can you lookup for figma-backup-root directory after the error occurs? (or any .fig files)

And did you manage to run the bot in a headful way? (with debug option)
What about your script? In your download.js script you have set the headless flag to false (which means it is going to be headful). Could you see the bot opening the chromium and does the task?

Answer 16 · 2022-09-14T20:07:30.000Z

They are tracking this bug since 2017 and yet It's not fixed, read more here.

Better to use the below solutions to download files.
using Puppeteer and Axios to download file.
A longer solution.

If you ask me using Axios is a good way to handle file downloads.

Answer 17 · 2022-09-15T07:38:17.000Z

Can you lookup for figma-backup-root directory after the error occurs? (or any .fig files)

Sure @mimshins jan,

I ran in both --debug mode enabled and disabled, unfortunately, nothing is there:

figma-backup-root/
├── backups
└── cookies.json

1 directory, 1 file

Could you see the bot opening the chromium and does the task?

@mimshins jan, I execute the command in a Linux server, so I cannot see opening the browser.

Answer 18 · 2022-09-15T08:02:44.000Z

@me-dira

Thanks Mehdi,
I will consider the solutions you've provided if I couldn't resolve the issue.

Answer 19 · 2022-09-15T08:13:34.000Z

Thanks @monegim,

figma-backup-root/
├── backups
└── cookies.json

1 directory, 1 file

So based on the results you gave me, it seems that you've found the figma-backup-root. Now based on the codebase:

downloadPath: path.join(
  BACKUP_DIR,
  SESSION_DATA.date!.toISOString(),
  projectName
)

The backups should be presented in the backups directory. The path to the files should be something like figma-backup-root/backups/2022-09-15T08:09:08.817Z/PROJECT_NAME/file1.fig.

Can you confirm?

Answer 20 · 2022-09-15T08:48:35.000Z

The backups should be presented in the backups directory.

Yes, but it is empty.

Answer 21 · 2022-09-15T09:01:22.000Z

I'm trying to find other ways to download files that don't depend on the browser or operating system.
I'll inform you the further information and progression.

Answer 22 · 2022-09-15T14:10:52.000Z

Update:

@mimshins jan,
I executed the figma-backup in windows too. It ran successfully, however, figma-backup-root is also empty.

 Directory of C:\Users\Mostafa\figma-backup-root\backups

09/15/2022  06:32 PM    <DIR>          .
09/15/2022  06:33 PM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  85,476,380,672 bytes free

The .fig files have been downloaded in the Downloads dir. Should it be so?

I also searched for any file with the .fig extension, but I could not find anything in the container:

root@db2fcca94266:~# find / -regex '.*\.fig$'
root@db2fcca94266:~#

Answer 23 · 2022-09-16T17:33:40.000Z

Update:

@mimshins jan, I executed the figma-backup in windows too. It ran successfully, however, figma-backup-root is also empty.
 Directory of C:\Users\Mostafa\figma-backup-root\backups

09/15/2022  06:32 PM    <DIR>          .
09/15/2022  06:33 PM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  85,476,380,672 bytes free
The .fig files have been downloaded in the Downloads dir. Should it be so?

I also searched for any file with the .fig extension, but I could not find anything in the container:
root@db2fcca94266:~# find / -regex '.*\.fig$'
root@db2fcca94266:~#

Well this is an issue with Windows OS. It doesn't support default download paths.

Answer 24 · 2022-09-16T17:36:57.000Z

@monegim

I have patched a few things, there's a good chance that the problem with Linux Machines has been fixed.
Please try out v1.0.4 and give me feedbacks.

Thanks Dear Mostafa.

Answer 25 · 2022-09-16T18:24:49.000Z

@mimshins jan,

It is resolved, now I can see the file in this directory:

/figma-backup-root/backups/2022-09-16T18:19:44.662Z/Team project

Answer 26 · 2022-09-16T18:28:53.000Z

Just a minor issue, when I ran the figma-backup --version, I still got 1.0.3:

root@664265bc2f08:~# figma-backup --version
1.0.3

Answer 27 · 2022-09-16T18:31:49.000Z

Just a minor issue, when I ran the figma-backup --version, I still got 1.0.3:
root@664265bc2f08:~# figma-backup --version
1.0.3

Oh I see!
I'm going to upgrade the puppeteer to its latest version (v17) and release figma-backup@2.0.0 in few days and I'll fix that version issue as well.

Thanks for your contribution ❤️🤝