Axum handler returns 400 on GET if datastar dictionary is missing

[thefiddler]

I tried to use rust-sdk v0.3.1 and hit a snag with ReadSignal<Option<T>> returning a 400 handler error instead of None when the datastar={...} parmeter is missing

• GET /dashboard?datastar={} returns ReadSignals<Option<T>> as None, as expected
• GET /dashboard returns a generic json deserialization error

The root cause seems to be that the ReadSignals extractor seems to handle the absence of a datastar param as an error, even if the user intentionally opts in to an Option<Foo> that could potentially be missing. In turn, this prevents using the same axum handler for both full-page loads and datastar-issued @get requests.

I was able to work around this by defining my own CustomReadSignals<T> extractor that handles missing datastar params for GET requests for ReadSignals<Option<T>>, but I was wondering if this is something that could be handled transparently by the rust sdk?

I have attached a repro case below, you can simply cargo run and hit:

• http://localhost:3000/ -> 400 error message
• http://localhost:3000/?datastar={"selected": "abc"} -> works

datastar_optional_signal.zip

[jkbh]

ReadSignals implements OptionalFromRequest. You would have to use signals: Option<ReadSignals<Option<T>>> to allow both variants.