[Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

[Chris S]

I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,

Chris.

[Mohamed Wael Khobalatte]

Was the glitch in the YAML structure itself (which normally would throw a parse exception and the app won't start), or was it a glitch in a value (value is "\sabc" vs "abc")? The latter is almost impossible to solve, considering that it hosts a wide variety of values, from API keys to your own secrets.

The way I deal with it is to try and figure out which values are just too important for the app, say a cache host credentials, then attempt a start of that service in an initializer, aborting the start the entire application of no values are found in the secrets file. 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--

Wael Khobalatte

[Chris S]

Good points.

I could have been more explicit about my exact problem

The glitch was that I’d indented `production`, so that the YAML parser was considering it a sub-key of `staging`. Obviously, accidentally deleting a character (`producion`, etc) would have similar effects.

I agree it’s probably scope-creep to deal with malformed keys anywhere in the file, but it doesn’t seem outrageous to check if there’s a top level key which matches the current RAILS_ENV, and bail if not?

Chris.

[Mohamed Wael Khobalatte]

Yes I think that would be a great addition. You will like reading this discussion: https://github.com/rails/rails/pull/17175. Extending one of the proposals there to require RAILS_ENV by default will solve your problem I think. 

[Chris S]

I like the ideas in that PR, although I’m not 100% qualified to comment on them (we don’t use env vars).

It does raise the problem that secrets.yml is lazily evaluated, so I don’t know if my suggested check would/could run at boot-time :/

Chris