Is your feature request related to a problem? Please describe.
constants() in src/infra/qobuz/dispatch.rs resolves the Qobuz web-player constants inline on the serial IoEvent pump on the first Qobuz event of a process: a login-page GET and, on a new bundle version, the 9 MB bundle GET (up to 120 s). Every other event, for every source, waits behind it. The code documents this as accepted for v1.
Describe the solution you'd like
Resolve the constants on a detached task and re-dispatch the event when they are ready, the way begin_login already spawns its wait. A more general option is letting a source router return "handled, run detached" so the service lane covers source events too.
Describe alternatives you've considered
Resolving at source selection time instead of at first use; the pump would still block if the user acts before the scrape finishes.
Additional context
From the review of #489.
Is your feature request related to a problem? Please describe.
constants()insrc/infra/qobuz/dispatch.rsresolves the Qobuz web-player constants inline on the serial IoEvent pump on the first Qobuz event of a process: a login-page GET and, on a new bundle version, the 9 MB bundle GET (up to 120 s). Every other event, for every source, waits behind it. The code documents this as accepted for v1.Describe the solution you'd like
Resolve the constants on a detached task and re-dispatch the event when they are ready, the way
begin_loginalready spawns its wait. A more general option is letting a source router return "handled, run detached" so the service lane covers source events too.Describe alternatives you've considered
Resolving at source selection time instead of at first use; the pump would still block if the user acts before the scrape finishes.
Additional context
From the review of #489.