[Bug]: Server - failed to deserialize: missing field `mail`

[pbek]

What did you expect to happen?

@ellie, @tessus

The field mail from #2190 was not generated automatically in server.toml.
And I didn't find anything in https://docs.atuin.sh/self-hosting/server-setup/#configuration.
Is there some documentation what is needed?

What happened?

When I run the latest docker image from https://github.com/atuinsh/atuin/pkgs/container/atuin (6e15286-amd64) for the first time, I get a:

 failed to deserialize: missing field `mail`

Atuin doctor output

atuin-server-1  | Error: could not load server settings
atuin-server-1  |
atuin-server-1  | Caused by:
atuin-server-1  |     failed to deserialize: missing field `mail`
atuin-server-1  |
atuin-server-1  | Location:
atuin-server-1  |     /app/crates/atuin-server/src/settings.rs:133:26

Code of Conduct

• I agree to follow this project's Code of Conduct

[tessus]

I am using the same config as in the guide I wrote on the forum. My server is atuin 18.3.0.

It could be possible that there's been a regression since then. I haven't tried git master server-side. I believe the issue is here:

https://github.com/atuinsh/atuin/blob/main/crates/atuin-server/src/settings.rs#L68

I believe it should be pub mail: Option<Mail>, instead.

[pbek]

For now, I got over the error with:

[mail]
enable = false

[tessus]

Yep, setting a default value in the builder should work too (after line 109):

    .set_default("mail.enable", false)?

[pbek]

By the way, is this feature turned on on the official server? I registered an account today and never got an email.

[tessus]

Idk, this is a question for ellie...

[ellie]

@pbek it is enabled, however we do not email users for verification by default. We don't even verify that what users submit as an email is an email.

Because of this, you can choose to verify or not verify. In the future, we will only support password recovery for verified emails, and if you choose not to do so you could lose access to your account.

It's still unreleased though, but if you're running a pre-release on the client as well as the server you can call atuin account verify.

[ellie]

Fixed :)

I appreciate you highlighting the issue, though you might have a better experience running a tagged release vs latest built image

[pbek]

Thank you very much for clarifying and for fixing!
And thank you very much for Atuin, I got reminded of it again in an article in https://www.linux-magazine.com/Issues/2024/281!

[pbek]

though you might have a better experience running a tagged release vs latest built image

Was this a note for me? Do you mean in my docker setup? I didn't find any other tags than the commit hashes. I'd much prefer "latest". 😊

[ellie]

It was! And yep in your docker setup. GitHub actions displays tags poorly, but all versions are valid tags

We don't ship latest intentionally. Releases may ship breaking changes, and following a moving tag will lead to your install not functioning. Self hosting is rarely just set and forget 😁

I'd pick the latest stable release, tag that, and update whenever you want/need to