I've been following along with the blog posts pretty regularly and everything has been going pretty smoothly. However, the most recent one has led to a bunch of headaches to get everything running properly again. I shut down the App on DigitalOcean in between chapters to keep the cost down, but I can't get it to spin back up. While troubleshooting this problem I discovered that the Github Workflows, Dockerflie, and Cargo.toml dependencies have all been updated between chapters without any mention.

I realize that this wouldn't happen if someone was reading a physical book straight through, but in the blog format, it is inevitable. Maybe at minimum there could be a quick note to the top of the chapter to check the dependencies first and follow the compiler for updating.

I get an error when trying to go through the very first code piece in the book. Here is how my project is setup and the error that I'm getting.

Cargo.toml:

[package]
name = "zero2prod"
version = "0.1.0"
authors = ["auth <[email protected]"]
edition = "2018"

[lib]
path = "src/lib.rs"

[[bin]]
path = "src/main.rs"
name = "zero2prod"

[dependencies]
actix-web = "=4.0.0-beta.9"
#actix-http = "=3.0.0-beta.10"

[dev-dependencies]
actix-rt = "1"
reqwest = "0.11"
tokio = { version = "1", features = ["macros"] }

Error:

error[E0432]: unresolved imports `actix_tls::connect::new_connector`, `actix_tls::connect::Connect`
  --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/connector.rs:17:5
   |
17 |     new_connector, Connect as TcpConnect, ConnectError as TcpConnectError,
   |     ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^ no `Connect` in `connect`
   |     |
   |     no `new_connector` in `connect`
   |
help: a similar name exists in the module
   |
17 |     connector, Connect as TcpConnect, ConnectError as TcpConnectError,
   |     ~~~~~~~~~
help: a similar name exists in the module
   |
17 |     new_connector, Connector as TcpConnect, ConnectError as TcpConnectError,
   |                    ~~~~~~~~~

error[E0432]: unresolved import `actix_tls::connect::Connect`
  --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/mod.rs:14:5
   |
14 |     Connect as TcpConnect, ConnectError as TcpConnectError, Connection as TcpConnection,
   |     -------^^^^^^^^^^^^^^
   |     |
   |     no `Connect` in `connect`
   |     help: a similar name exists in the module: `Connector`

error[E0282]: type annotations needed
   --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/connector.rs:267:28
    |
267 |     pub fn finish(self) -> ConnectorService<S, Io> {
    |                            ^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `Io`

error[E0282]: type annotations needed
   --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/connector.rs:531:13
    |
531 | impl<S, Io> Service<Connect> for TcpConnectorInnerService<S>
    |             ^^^^^^^^^^^^^^^^ cannot infer type for type parameter `Io`

error[E0282]: type annotations needed
   --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/connector.rs:546:8
    |
546 |     fn call(&self, req: Connect) -> Self::Future {
    |        ^^^^ cannot infer type for type parameter `Io`

error[E0282]: type annotations needed
   --> /Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-http-3.0.0-beta.10/src/client/connector.rs:544:5
    |
544 |     actix_service::forward_ready!(service);
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `Io`
    |
    = note: this error originates in the macro `actix_service::forward_ready` (in Nightly builds, run with -Z macro-backtrace for more info)

If I try to move to non-beta versions of the actix dependencies (and nothing else), I get actix panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime'. So I'm stuck and cannot proceed. Please advise!

I'm using Rust 1.64 stable. Adding the sqlx 0.6 dependency doesn't compile the project.

Cargo.toml

[dependencies]
actix-web = "4"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }
serde = { version = "1", features = ["derive"] }
config = { version = "0.13", default-features = false, features = ["yaml"] }
uuid = { version = "1", features = ["v4"] }
chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
sqlx = { version = "0.6", features = ["runtime-actix-rustls", "macros", "postgres", "uuid", "chrono", "migrate"] }

Using cargo +nightly build works fine.

Putting it here if other people are running into a similar issue

I'm seeing this error every now and then. Sometimes when adding dependencies manually or just now after trying your latest release of tracing-actix-web 0.4.0-beta.1. I believe I first saw it after mistakenly adding actix-web-4.0.0-beta.6 instead of beta.3 as specified in the book.

error[E0277]: the trait bound `fn(Form<subscriptions::FormData>, actix_web::web::Data<Pool<Postgres>>) -> impl std::future::Future {subscriptions::subscribe}: Handler<_, _>` is not satisfied
  --> src/startup.rs:15:53
   |
15 |             .route("/subscriptions", web::post().to(subscribe))
   |                                                     ^^^^^^^^^ the trait `Handler<_, _>` is not implemented for `fn(Form<subscriptions::FormData>, actix_web::web::Data<Pool<Postgres>>) -> impl std::future::Future {subscriptions::subscribe}`

Should be reproducible by setting actix-web = "=4.0.0-beta.6" in Cargo.toml. Perhaps even without the = qualifier. Setting actix-web = "=4.0.0-beta.3" makes all hell break lose, so I'm guessing it's all caused by other crates' dependencies.

I usually fix it by doing cargo clean and replacing my Cargo.lock with the one from your repository and branch for the chapter I am on. Currently root-chapter-07

However, I was hoping you would know if there's a way to fix it for good, and avoiding problems like these? Or even just point me in the right direction and I might be able to figure it out on my own.

PS: I'm only a few weeks old in the Rust world, and I am really enjoying the book. Outstanding work!

Compiling sqlx-rt v0.2.0
error: one of the features ['runtime-actix-native-tls', 'runtime-async-std-native-tls', 'runtime-tokio-native-tls', 'runtime-actix-rustls', 'runtime-async-std-rustls', 'runtime-tokio-rustls'] must be enabled
  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/sqlx-rt-0.2.0/src/lib.rs:9:1
   |
9  | / compile_error!(
10 | |     "one of the features ['runtime-actix-native-tls', 'runtime-async-std-native-tls', \
11 | |      'runtime-tokio-native-tls', 'runtime-actix-rustls', 'runtime-async-std-rustls', \
12 | |      'runtime-tokio-rustls'] must be enabled"
13 | | );
   | |__^

error: aborting due to previous error

error: could not compile `sqlx-rt`.

Amazing work on all of this so far! I'll be looking to add the "distroless" musl setup from https://dev.to/sergeyzenchenko/actix-web-in-docker-how-to-build-small-and-secure-images-2mjd soon!

Instead of creating a bunch of small issues for typos, I'll list them all as separate comments on this one issue.

In the Sharing Startup Logic code block it identifies the wrong file:

//! tests/app/helpers.rs

should be:

//! tests/api/helpers.rs

Obviously I'm a Rust noob, so please bear that in mind. Specifically I have not used any Rust DB library. Many readers will be too and will be relying on choices made here.

After a cursory review of Diesel issue: diesel-rs/diesel/issues/399 I'm nervous about sqlx.

I don't think you addressed their substantive reasons for not offering an async API.

Are you indicating the sqlx has resolved those issues in their crate? If so could you say so explicitly? It would also be informative to know if it is your opinion that the Diesel reservations are unfounded? Unreasonably conservative? You didn't hold back on the use of executable business documents ;) Frank and forthright is generally valuable.

In fact the Diesel reasons for their choice of sync and your reasons for recommending a relational DB are pretty much the same. Repurposing you relational DB statement, one could say this is reasonable description of the state-of-play in Diesel:

Syncronous database APIs are reasonably good as jack-of-all-trades: they will often be a good choice when building the first version of your application, supporting you along the way while you explore the constraints of your domain.

Yet when it comes to a DB library you guide to a choice, sqlx, that IMO is high risk, for no return that I'm aware of. The risk is some less experienced user relying on the async API while using transactions. I could be wrong but there is no reasonable assurance that your app will only hit issues with transaction issues that leave incomplete transactions at very high 'Google' scale volumes.

The risk-return trade-off gets worse for sqlx when you consider that there are Rust crates r2d2 and bb8, helping you handle increased workloads. If your app scales beyond that capacity, (+sharding) then you should be looking at the toys the big kids are playing with.

While I haven't read the whole book, I wonder if there isn't a lost opportunity to add r2d2, bb8, or some such crate, as a step to production? Perhaps this comes up later?

When running under WSL2, binding only to localhost via the 127.0.0.1 address only lets you access the server from within WSL2 itself. It does not allow you to access the server from Windows.

With this change, you can access the web server from the WSL ip address. You can find your WSL ip address with

$ ip a | grep eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.161.12/20 brd 192.168.175.255 scope global eth0

Im up to pg 38 where we need to update main.rs and run cargo check.

Im trying to figure out what i've done wrong here and note that by the end of the chapter you have introduced an address fn into main.

Here's the cargo test output: ╰─ cargo test ─╯ Compiling zero2prod v0.1.0 (.../zero2prod) error[E0061]: this function takes 1 argument but 0 arguments were supplied --> src/main.rs:6:5 | 6 | run()?.await | ^^^-- an argument of type &str is missing | note: function defined here --> /.../zero2prod/src/lib.rs:10:8 | 10 | pub fn run(address: &str) -> Result<Server, std::io::Error> { | ^^^ help: provide the argument | 6 | run(/* &str */)?.await

Hi. I enjoyed the book and learned a lot already, but I've had a lot of issues with deployment on Digital Ocean App Platform. My first issue was the Out Of Memory error, https://github.com/LukeMathWalker/zero-to-production/issues/71, which I resolved by building the image with a GA workflow and deploying with that image. I originally had some weird issues with deploying the DB, but I resolved it.

However, after successfully deploying the app with the DB, I get a 500 on post requests to /subscriptions. I've checked the env vars in the DO console as instructed here: https://docs.digitalocean.com/products/app-platform/how-to/use-environment-variables/ -> echo $<name-of-environment-variable>, and they are correct and the same as the connection parameters of the database. I've searched through my code, compared it to the book code, the book repo code and some other peoples solutions.

Locally everything is fine and tests pass. The issue seems to be with the connection to the DB in production, as the query fails with Connection pool timed out. The health check passes. In the DO runtime logs I get the expected output in the app logs:

ADDING A NEW SUBSCRIBER - START  
SAVING NEW SUBSCRIBER DETAILS IN THE DATABASE - START  
SAVING NEW SUBSCRIBER DETAILS IN THE DATABASE - EVENT Failed to execute query: PoolTimedOut  
etc...

In the DO database runtime logs I see no output when sending the request.

My app spec: https://github.com/oddgrd/zero2prod/blob/main/spec.yml My image builder workflow: https://github.com/oddgrd/zero2prod/blob/main/.github/workflows/push-image.yml My configuration file: https://github.com/oddgrd/zero2prod/blob/main/src/configuration.rs

I assume the issue here is something simple I have missed or misunderstood, but I'd be grateful if someone could have a look. Great book, thanks!

I followed along the book, reached 7.3.8 Sharing Startup Logic section, until I started to struggle due to inconsistency inside code blocks (compiler started to complain EmailClient::new takes 4 parameters, but 3 provided etc)

I decided to go back to the end of 7.3.7 (I quite often do snapshots), but turned out I can no longer compile the code :(

Since then I tried jumping across multiple snapshots, but without any luck.

Also the issue seems to be referring to some issue when building dependency, rather than 'my' code itself.

 cargo build
    Updating crates.io index
  Downloaded actix-codec v0.4.2
  Downloaded bytestring v1.0.0
  ...
   Compiling actix-http v3.0.0-beta.18
   Compiling sqlformat v0.1.8
   Compiling hyper v0.14.16
   Compiling sqlx-core v0.5.10
   Compiling actix-web v4.0.0-beta.19
error[E0107]: this trait takes 0 generic arguments but 1 generic argument was supplied
   --> /Users/arkad/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-4.0.0-beta.19/src/service.rs:310:6
    |
310 | impl Resource<Url> for ServiceRequest {
    |      ^^^^^^^^----- help: remove these generics
    |      |
    |      expected 0 generic arguments
    |
note: trait defined here, with 0 generic parameters
   --> /Users/arkad/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-router-0.5.0-rc.1/src/resource_path.rs:5:11
    |
5   | pub trait Resource {
    |           ^^^^^^^^

error[E0046]: not all trait items implemented, missing: `Path`
   --> /Users/arkad/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-4.0.0-beta.19/src/service.rs:310:1
    |
310 | impl Resource<Url> for ServiceRequest {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `Path` in implementation
    |
    = help: implement the missing item: `type Path = Type;`

Some errors have detailed explanations: E0046, E0107.
For more information about an error, try `rustc --explain E0046`.
error: could not compile `actix-web` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

I'm completely lost with this one, wasn't there before and now I cannot continue. I am stuck - cannot compile any version right now.

I am on Macos, cargo version 1.58.0 (7f08ace4f 2021-11-24).

In section 11.9.1 , the test concurrent_form_submission_is_handled_gracefully continues to fail with this error message even after following all the steps:

running 1 test
test newsletter::concurrent_form_submission_is_handled_gracefully ... FAILED

failures:

---- newsletter::concurrent_form_submission_is_handled_gracefully stdout ----
thread 'newsletter::concurrent_form_submission_is_handled_gracefully' panicked at 'Verifications failed:
- Mock #1.
	Expected range of matching incoming requests: == 1
	Number of matched incoming requests: 2

Received requests:
- Request #1
	POST http://localhost/email
x-postmark-server-token: my-secret-token
content-type: application/json
accept: */*
host: 127.0.0.1:60806
content-length: 418
{"From":"[email protected]","To":"[email protected]","Subject":"Welcome!","HtmlBody":"Welcome to our newsletter!<br />Click <a href=\"http://127.0.0.1/subscriptions/confirm?subscription_token=u7kEEzL4zaKFuyXjzZ5qKWtK8\">here</a> to confirm your subscription.","TextBody":"Welcome to our newsletter!\nVisit http://127.0.0.1/subscriptions/confirm?subscription_token=u7kEEzL4zaKFuyXjzZ5qKWtK8 to confirm your subscription."}
- Request #2
	POST http://localhost/email
x-postmark-server-token: my-secret-token
content-type: application/json
accept: */*
host: 127.0.0.1:60806
content-length: 166
{"From":"[email protected]","To":"[email protected]","Subject":"Newsletter title","HtmlBody":"<p>Newsletter body as HTML</p>","TextBody":"Newsletter body as plain text"}
- Request #3
	POST http://localhost/email
content-type: application/json
host: 127.0.0.1:60806
accept: */*
x-postmark-server-token: my-secret-token
content-length: 166
{"From":"[email protected]","To":"[email protected]","Subject":"Newsletter title","HtmlBody":"<p>Newsletter body as HTML</p>","TextBody":"Newsletter body as plain text"}
', /Users/tesseract/.cargo/registry/src/github.com-1ecc6299db9ec823/wiremock-0.5.16/src/mock_server/exposed_server.rs:361:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    newsletter::concurrent_form_submission_is_handled_gracefully

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 26 filtered out; finished in 4.00s

This is because the Mock in the test concurrent_form_submission_is_handled_gracefully "expects" 1 response instead of 2. The fix is easy, change the value of expect() from 1 to 2.

#[tokio::test]
async fn concurrent_form_submission_is_handled_gracefully() {
    // Arrange
   // [...]
    Mock::given(path("/email"))
        .and(method("POST"))
        .respond_with(
            ResponseTemplate::new(200).set_delay(Duration::from_secs(2)),
        )
     // fix here 👇
        .expect(2)
        .mount(&app.email_server)
        .await;
     // [...]
}

The test should pass.

Description

Postmark during registration accepts only work emails. They also described it in the article https://postmarkapp.com/blog/why-cant-i-use-gmail-address

Suggestion

MailChimp allows you to register on your Google domain and provides a free option for a small email sender. Maybe it would help.

In the indicated chapter it is proposed to use the function connection_string_without_db() to connect to the Postgress instance, but not to a specific database. This does not seem to be aligned with Postgress expectations, since if the database is not indicated it is defaulted to the value of the user. Example for user user:

thread 'register_offer_returns_400_for_invalid_data' panicked at 'Failed to connect to Postgress: Database(PgDatabaseError { severity: Fatal, code: "3D000", message: "database \"testst\" does not exist", detail: None, hint: None, position: None, where: None, schema: None, table: None, column: None, data_type: None, constraint: None, file: Some("postinit.c"), line: Some(941), routine: Some("InitPostgres") })', tests/healthj_check.rs:111:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am no expert in backend/dbs at all, so I checked on the internet and there seems to be a known behavior:

• https://stackoverflow.com/questions/4483139/how-do-i-connect-to-postgresql-without-specifying-a-database-name
• https://stackoverflow.com/questions/51015561/how-to-connect-to-postgresql-db-without-a-database-name-from-aws-rds

Both recommend using postgres database, which I tried and works as expected.

The third act of the test 'an_error_flash_message_is_set_on_failure()'

let html_page = app.get_login_html().await;
assert!(!html_page.contains(r#"<p><i>Authentication failed</i></p>"#));

only succeeds because there is a period missing after failed. If we replace the last part with assert!(html_page.contains(r#"<p><i>Authentication failed.</i></p>"#)); it passes, and it becomes evident that "

Authentication failed.

cargo check returns

error[E0277]: the trait bound `i16: MessageBody` is not satisfied
   --> src/idempotency/persistence.rs:50:31
    |
50  |         Ok(Some(response.body(r.response_body)))
    |                          ---- ^^^^^^^^^^^^^^^ the trait `MessageBody` is not implemented for `i16`
    |                          |
    |                          required by a bound introduced by this call
    |
    = help: the following other types implement trait `MessageBody`:
              &'static [u8]
              &'static str
              ()
              BodyStream<S>
              Box<B>
              BoxBody
              BytesMut
              EitherBody<L, R>
            and 15 others
note: required by a bound in `HttpResponseBuilder::body`
   --> /home/ryantin/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-4.2.1/src/response/builder.rs:292:12
    |
292 |         B: MessageBody + 'static,
    |            ^^^^^^^^^^^ required by this bound in `HttpResponseBuilder::body`

Just to make sure its not just me, I clone the current repository and faced the same compiler error