ERR. Download aborted - Githubissues

mostafaznv commented 2 years ago

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)

mimshins commented 2 years ago

@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.

Believemenot commented 2 years ago

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

mimshins commented 2 years ago

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

mostafaznv commented 2 years ago

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.

Believemenot commented 2 years ago

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)

mimshins commented 2 years ago

@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

mimshins commented 2 years ago

@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?

Believemenot commented 2 years ago

> 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)

mostafaznv commented 2 years ago

@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.

mimshins commented 2 years ago

@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?

mimshins commented 2 years ago

@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

mimshins commented 2 years ago

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.

monegim commented 2 years ago

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)

5. I found a workaround ([this](https://stackoverflow.com/questions/60304251/unable-to-open-x-display-when-trying-to-run-google-chrome-on-centos-rhel-7-5/61043049#61043049)):
```bash
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?

mimshins commented 2 years ago

@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.

mimshins commented 2 years ago

@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?

mehdi-ra commented 2 years ago

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.

monegim commented 2 years ago

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.

mimshins commented 2 years ago

@me-dira

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

mimshins commented 2 years ago

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?

monegim commented 2 years ago

The backups should be presented in the backups directory.

Yes, but it is empty.

mimshins commented 2 years ago

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.

monegim commented 2 years ago

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:~#

mimshins commented 2 years ago

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.

mimshins commented 2 years ago

@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.

monegim commented 2 years ago

@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

monegim commented 2 years ago

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

mimshins commented 2 years ago

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 ❤️🤝

mimshins / figma-backup

ERR. Download aborted #6