Capistrano's /current folder always points to the same (non-existent) release - capistrano

Question

My capistrano release appears to be "sucked", since no matter how many cap production deploys I send, the /current folder is generated over and over again pointing to the same folder.
# Trying to open /current with FTP Sync
Command: CWD /public_html/storekey-demo/releases/20180813141339
Response: 550 /public_html/storekey-demo/releases/20180813141339: No such file or directory
Error: Failed to retrieve directory listing
Even after deleting the /current folder, the /releases folder, the /repo folder, the /temp folder, and the revisions.log file, and running capistrano again, the symlink is created pointing to the same folder. I think I've tried everything I can think of.
This is my deploy.rb file
lock "~> 3.11.0"
set :application, "storekey_demo" # don't use "-"
set :repo_url, "git#gitlab.com: xxxxxxxxxxx .git"
set :deploy_to, "/home/u0000000/public_html/storekey-demo"
set :tmp_dir, '/home/u0000000/public_html/tmp'
namespace :deploy do
desc "Build"
after :updated, :build do
on roles(:web) do
within release_path do
execute :composer, "install --no-dev --quiet --optimize-autoloader"
end
end
end
end
namespace :deploy do
desc "Copy Env"
after :finished, :copy do
on roles(:all) do
upload! "production.env", "#{current_path}/.env"
end
end
end
This is my deploy log, as you can see there are no errors
> cap production deploy
00:00 git:wrapper
01 mkdir -p /home/u000000000/public_html/tmp
✔ 01 u000000000#185.201.11.23 7.806s
Uploading /home/u000000000/public_html/tmp/git-ssh-storekey_demo-production-francisco.sh 100.0%
02 chmod 700 /home/u000000000/public_html/tmp/git-ssh-storekey_demo-production-francisco.sh
✔ 02 u000000000#185.201.11.23 0.445s
00:09 git:check
01 git ls-remote git#gitlab.com: xxxxxx .git HEAD
01 75bb7ded165efb968f00d29808b0673d7517aa41 HEAD
✔ 01 u000000000#185.201.11.23 1.438s
00:10 deploy:check:directories
01 mkdir -p /home/u000000000/public_html/storekey-demo/shared /home/u000000000/public_html/storekey-demo/releases
✔ 01 u000000000#185.201.11.23 0.399s
00:12 git:clone
The repository mirror is at /home/u000000000/public_html/storekey-demo/repo
00:12 git:update
01 git remote set-url origin git#gitlab.com: xxxxxxx .git
✔ 01 u000000000#185.201.11.23 0.465s
02 git remote update --prune
02 Fetching origin
✔ 02 u000000000#185.201.11.23 1.537s
00:15 git:create_release
01 mkdir -p /home/u000000000/public_html/storekey-demo/releases/20180813165948
✔ 01 u000000000#185.201.11.23 0.455s
02 git archive master | /usr/bin/env tar -x -f - -C /home/u000000000/public_html/storekey-demo/releases/20180813165948
✔ 02 u000000000#185.201.11.23 6.387s
00:23 deploy:set_current_revision
01 echo "75bb7ded165efb968f00d29808b0673d7517aa41" > REVISION
✔ 01 u000000000#185.201.11.23 0.443s
00:24 deploy:build
01 composer install --no-dev --quiet --optimize-autoloader
✔ 01 u000000000#185.201.11.23 6.045s
00:30 deploy:symlink:release
01 ln -s /home/u000000000/public_html/storekey-demo/releases/20180813165948 /home/u000000000/public_html/storekey-demo/releases/current
✔ 01 u000000000#185.201.11.23 25.267s
02 mv /home/u000000000/public_html/storekey-demo/releases/current /home/u000000000/public_html/storekey-demo
✔ 02 u000000000#185.201.11.23 0.421s
00:56 deploy:cleanup
Keeping 5 of 6 deployed releases on 185.201.11.23
01 rm -rf /home/u000000000/public_html/storekey-demo/releases/20180813164636
✔ 01 u000000000#185.201.11.23 0.543s
00:58 deploy:log_revision
01 echo "Branch master (at 75bb7ded165efb968f00d29808b0673d7517aa41) deployed as release 20180813165948 by francisco" >> /home/u000000000/publ…
✔ 01 u000000000#185.201.11.23 0.530s
00:59 deploy:copy
Uploading production.env 100.0%

Answer 1

It seems like the problem was in FileZilla itself, and not in capistrano.
I entered through the SSH console in my server and deleted the /current symlink, then created it again pointing to the last build, and run capistrano production deploy. The problem is fixed and changes are being deployed correctly, but FireZilla is still not recognizing the symlink correctly.