<@U06A03HV1> re this proposal to fix `session.prod...
# development
h
@witty-crayon-22786 re this proposal to fix
session.product_request()
failing when
--dynamic-ui
is enabled but the console has been torn down:
The answer might be to make the "render the UI" flag a per-product_request method call flag, rather than a Session-level flag,
Thoughts on keeping the Session-level flag, but then adding a bool override to
ExecutionRequest
to force no console?
Getting rid of the Session-level flag looks like it will change a lot of code and require us to pass through
--dynamic-ui
in more places, fwict
w
the only place it will be true is in
run_goal_rules
👍 1
which i think limits how many places it needs to be passed
it could just be a boolean on ExecutionRequest i think?
h
Sg, that looks like the right spot. Now to figure out how to wire it up in Rust correctly
w
if that’s right, then i think it would be easiest to remove setting it during construction of the Session… but maybe i’m wrong
👍 1
h
(Pardon that I haven't dived into the Rust code closely yet) - naively, the issue with that would be re-setting up the dynamic UI every product_request, right? We only want to init once iiuc
w
@hundreds-father-404: we set up a new “instance” of the UI for each call to Scheduler::execute, and that’s the bulk of the UI setup time
👀 1
👍 1
and so i think that moving the entire “which rendering mode should we use” logic into
execute
should not make a difference in runtime