Make handlers lazy-loadable via Zeitwerk #11
Comments
Merged
julik
added a commit
that referenced
this issue
Jul 23, 2024
Most mistakes in webhook configuration are usually related to the configuration of the secrets for signatures. While it is good in some situations to reject the incorrectly signed webhooks immediately, in way more situations it will actually be the misconfigured signature that'll be at fault. A better approach is to allow the webhooks to be respooled for processing when the signature configuration has been rectified. - Use `valid?` in the background job instead of the controller. Most common configuration issue is an incorrectly specified signing secret, or an incorrectly implemented input validation. When these happen, it is better to allow the webhook to be reprocessed - Use instance methods in handlers instead of class methods, as they are shorter to define. Assume a handler module supports `.new` - with a module using singleton methods it may return `self` from `new`. - In the config, allow the handlers specified as strings. Module resolution in Rails happens after the config gets loaded, because the config may alter the Zeitwerk load paths. To allow the config to get loaded and to allow handlers to be autoloaded using Zeitwerk, the handler modules have to be resolved lazily. This also permits the handlers to be reloadable, like any module under Rails' autoloading control. - Simplify the Rails app used in tests to be small and keep it in a single file - If a handler is willing to expose errors to the caller, let Rails rescue the error and display an error page or do whatever else is configured for Rails globally. - Store request headers with the received webhook to allow for async validation Closes #12 #11 --------- Co-authored-by: Stanislav Katkov <[email protected]>
|
Closed via #13 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment our "official" way to mount handlers is to specify them in the global config. The issue though, is that this config loads earlier in the Rails lifecycle and Zeitwerk does not yet take over there, meaning that
requireis needed, which goes against the Rails expected behaviorWhat we could do:
active_handlers =it would be aactive_handlers do...constantized at call site. This way the controller would be resolving the module - by this time the autoloading of the handlers will be availableThe text was updated successfully, but these errors were encountered: