In short, when Flash scoped attributes are added in a @Controller method and then a redirect is executed by returning a type of ResponseEntity with an HTTP status of 302 Found, the Flash scoped attributes are lost.
RedirectAttributes, and also model attributes, are used when rendering through view resolution with a view and a model. Support for flash attributes was exposed through RedirectAttributes because it fits the redirect scenario but also because flash scope commonly comes up in browser applications for displaying a message after a post, etc. REST controllers tend to be more stateless.
So technically not a bug but rather an enhancement request. It shouldn't be hard to add. It's just a thin layer over the underlying FlashMapManager. That said I'm curious if you could share a little more about your use case.
Sure thing - I have written a helper library I used to manage messages of various severity levels (e.g. INFO / WARNING / ERROR / SUCCESS), in HTML views as you mentioned. Naturally I use redirect attributes / flash scope to preserve these messages across redirects.
I had a Controller class with mixed View rendering (e.g. String return types) and some REST-ish methods handling AJAX calls (methods with ResponseEntity<SomePayload> return types). I ended up writing a few POST handling methods which always result in redirects that were using a helper method ( return redirect("/location", statusCode) ) which built a ResponseEntity. Having been using ResponseEntity lately because I like the builder/explicit style, I just assumed that any redirection returned from a method in a controller would work with Flash scope.
So, having said all that, I don't have a special REST/stateful use case, so much as I was just expecting different behaviour.
Learned something new today - thanks for your quick feedback Rossen.
Thanks for the extra details Edward Smith. Good to hear also about the preference to use ResponseEntity because of its API. Note that we are planning a similar API for view resolution purposes with #19775. That's for use on the reactive side, in the new WebFlux module but no reason why the same couldn't be applied to the WebMVC module as well.