Import Aliases does not work at all

[xanthos84]

Support guidelines

• I've read the support guidelines

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

Import Aliases feature does not work on v.1.1.0

Expected behaviour

it should import aliases to the database

Actual behaviour

after importing, the finished email with "323 aliases had validation failures" and 0 being imported.

beside that "429 TOO MANY REQUESTS" if you want to try to upload the csv even though you just tried it once.

Steps to reproduce

create simple csv file
like the template:

alias,description,recipients
[email protected],ok,[email protected]

Docker info

Client: Docker Engine - Community
 Version:    24.0.2
 Context:    default
 Debug Mode: false

Server:
 Containers: 11
  Running: 11
  Paused: 0
  Stopped: 0
 Images: 15
 Server Version: 24.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 4.15.0-213-generic
 Operating System: Ubuntu 18.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.899GiB
 Name: d1
 ID: 3290eba2-4ce4-4726-97ed-xxxxxx
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

Docker Compose config

No response

Logs

no log file even though in debug mode.

Additional info

No response

[buxm]

I tried to import aliases exported from another anonaddy instance.
I got the following screen:

and the following line on the logs:

172.20.0.2 - - [27/Jun/2024:19:38:38 +0200] "POST /settings/aliases/import HTTP/1.1" 429 6632 "https://mydomain.com/settings/data" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36"

[buxm]

I had chance to play with this a little more.
First, the Import Aliases function has a rate limit of 1 per minute.
This means that if you click the "Import Alias Data" button once and then click on it again within the same minute, you get an HTTP 429 ("too many requests") error. Only after 1 minute has gone by since you last clicked it you can try again without getting that error.
When I performed my first test on it, I probably clicked on the button after selecting the wrong file, got another type of error which I disregarded because it was due to my mistake, then tried again shortly after and got the "too many requests" error that I reported in my previous post.
But I have to say that the reason for the "too many requests" error is not very clear and if you first get another type of error you would naturally try to fix your mistake and retry within a minute.

I have now given another try importing the file I had exported from another Addy.io instance and got the error "The aliases import file has invalid headers, please use the template provided above.".
Then I looked at the exported file and realised its headers are completely different from those required by the import function.
I intuitively gave it for granted that the export and import format were the same, to allow a user to export from an instance and import into another one. But clearly that's not the case.
So I manually modified the exported csv file to make it comply with the import template and then I managed to successfully import it.

@xanthos84's you made a first attempt which resulted in 323 validation failures. Then you probably made another attempt within a minute getting the "too many requests" error. If you try again after more than one minute you shouldn't encounter the same error.
While the 323 validation failures are difficult to debug considering that the operation seems to produce no logs. But maybe looking at the actual file you are trying to import it's possible to find out what could cause the failure.

@willbrowningme although I managed to resolve my issues and woudn't call them a bug, I can see that some choices may be a bit counterintuitive and/or mislead users into reporting issues.
As an improvement on this, I can give the following suggestions, thay you may (or may not) wish to implement:

1. increase a bit the rate limit on the import aliases function so to still avoid abuse but at the same time allow users to retry immediately if they got an error
2. or alternatively impose a rate limit only on successful alias imports, so that users can retry immediately after an error
3. or alternatively clearly state on the UI that you can import only once per minute
4. ...or disable the import button with a countdown from 60s to 0 after clicking on it
5. make the export and import csv templates compatible, so that it's easier to export from an instance and import into another one