Type safe state inheritance

[davidpdrsn]

Lately I've been wanting to explore a more type safe way to passing state to routers, that don't run things like #1516. It think its a little unfortunate that axum 0.6's headline feature is type safe state, only for inherit_state to not actually be type safe.

This changes the API such that Router::with_state requires the state which is then passed to everything when building the final RouterService:

let service: RouterService = Router::new()
    .route(...)
    .with_state(state);

The upside of this approach is that we don't need additional type parameters or runtime stuff to track whether the state has been supplied or not.

Nesting (and merging) is only possible with a Router which doesn't have the state so it becomes more type safe. You can still use nest_service but that requires turning the Router into a RouterService by supplying the state.

@jplatte what do you think?

Fixes #1516

TODO

• Update docs
• Changelog

[jplatte]

You can still use nest_service but that requires turning the Router into a RouterService by supplying the state.

I think the reason I didn't do it this way is that you then can't have fallback inheritance for nested routers that have a different state type.

[davidpdrsn]

I think the reason I didn't do it this way is that you then can't have fallback inheritance for nested routers that have a different state type.

Yeah I ran into that here. I changed nest and merge to require the same state type. I think thats an okay compromise. I think I'd rather have type safety.

[jplatte]

Well, I still somewhat strongly prefer the previous compromise because while you could be surprised about that too, the surprise with nesting a RouterService and expecting fallback inheritance to work same as with nesting a Router can happen while the service is already in prod. That's not the case with the panic from attempting to turn an inheriting Router into a service, whether directly or indirectly.

[jplatte]

We discussed this on Discord (privately, sorry) and because of how state inheritance is implemented now, this can't actually cause the problem that I was worried about.

I guess it makes it impossible to merge two routers with different state though? Maybe that's fine. It's at least not something that you notice when the service is already running 🙂

[jplatte]

The changelog for this is very weird, I only noticed now. There is a double : and it talks about inherit_fallback and that you should use with_state (rather than just new).

[davidpdrsn]

@jplatte oh good catch! Fixed in 2e3000f

[zvkemp]

This change seems to have broken into_make_service() for routers not using the default state; was that decision was intentional? As IntoMakeService::new() is crate-private, it's unclear how we are now supposed to serve routers with a custom state.

[davidpdrsn]

@zvkemp it didn't. You gotta call Router::with_state to provide the state. See the examples in the docs or in the repo.

[zvkemp]

Yes, we are calling with_state (the newer version as of 0.6.0.rc5).

This method (as well as into_make_service_with_connect_info) is only implemented on Router<(), B>, not Router<S, B> as it was previously.

https://docs.rs/axum/0.6.0/axum/routing/struct.Router.html#method.into_make_service

[zvkemp]

Oh actually I think I understand what is happening — I didn't realize that the signature of with_state doesn't specify that the state argument will become the router's state, and we had a type hint specifying our router would be built as a Router<MyState, _> rather than the required Router<(), _> for it to be a Service. Removing that type hint fixes the issue.

[jplatte]

Exactly. Next time if you have an issue though, please open a discussion with a reproducible example instead of posting to a merged PR.