Fixes#10Fixes#99
Connects to #116
This was my first experience messing with the queues part of the service, I thought dealing with these issues first would make the experience smoother. I added the standard logging and error handling with the failure crate just like the rest of the lib.
Since our errors were very much centered around requests and rocket, we have some fields that don't really make sense for the queues process, like the http code, so let me know what you think about that and if the queues process should have a different error format. I also did another minor change to the errors: now the response JSON will return a number for code and errno, instead of a string.
For logging, I implemented an AppErrorFields so that we get better structured logs for our AppErrors. I used slog_scope to make it easier to have a global logger for the queues process, let me know what you think about that... In the README.md for that crate, they have some warnings about it not being the best idea all the time, but anyways, I thought it was neat and worked well for our case.
Finally, when I started working in the queues they were not really working due to parsing errors, you will see that I changed a little bit the SQS Notification struct, that was for parsing to work, also I created a notification-dev queue in the AWS Console, because it didn't exist yet, I think everything is working fine now.
Over in https://github.com/mozilla/fxa-auth-server/pull/2535, work is
being done to enable the auth server to specify the provider for
specific requests. This causes a problem in fxa-local-dev, because we
always want to use the local smtp provider there.
As a hackish approach to resolving that conflict, this change introduces
a new boolean setting called `forceprovider`. If `forceprovider` is
`true`, the default provider may not be overridden by individual
requests.
Fixes#146
When I changed to use Rocket::custom instead of Rocket.toml for creating configuration, I forgot about ROCKET_SECRET_KEY.
It's good to note that, because we are using Rocket::custom none of the ROCKET_ env vars will work, so if ever we need to set any of the fields in config, we need to add to our config and to our rocket config builder function.
These are the possible fields in rocket config: https://api.rocket.rs/rocket/config/struct.ConfigBuilder.html#fields
Fixes#130.
We don't want the regular cycle of conflicts between Rust nightlies and (usually) rocket codegen to affect us in prod. And, funnily enough, the version that I first tried pinning to contains one of those of conflicts, so good reminder there. (nightly 2018-07-15 works with Rocket 0.3.15, but we're pinned to a specific commit on master for now)
Fixes#111
In order to do this I had to point our rocket version to the Rocket repo and that introduced some breaking changes which I also fixed in this PR. Mostly they were variable name changes
Fixes#100Fixes#24
As mentioned in #24 we still need to see about ROCKET_WORKERS.
Also, in production, rocket sends a warning about not having set a secret_key, but I decided to leave it without anything for now. Anyways that would be something that probably we wouldn't "hard code" here.
Fixes#82
When we are in a testing environment (which means when NODE_ENV=test) the logger won't show anything.
So now, instead of having mozlog:true | false in the config, we have logging: null | pretty | mozlog.
Fixes#48Fixes#77
I had to change basically everything since my last PR (#85) about this, so I thought it would be best to just create a new PR.
To get the failure errors working I needed to get at least providers, bounces and db to also work with the failure errors, not just the Rocket and HTTP errors. That's what I'm doing in this PR. Since this is kind of a big change, I thought it would be best to send this in before adapting the tests to the new error type, so, right now, many tests are commented.
Let me know what you guys think. If you think this is a good change I still would need to adapt all tests and also there are some error types specially for the queues bin that need to be changed as well.
I personally think this is a good change. It is abstracting all the errors to one single place in the code. While working on this refactoring, I saw a bunch of repeated code for error handling. This ends that, which means it will be easier to maintain and create new error types with this way of doing things. Also, we are now getting much more information about each error, not just the HTTP status and message and it's very easy to customize this even further.
Beatriz Rizental
Phil Booth
Vlad Filippov
John Morrison