feat(workflow): drive workflows as nodes and remove WorkflowAgent - #688
Conversation
kalenkevich
changed the title
5db5fcb to
a5040e1
Compare
AmaadMartin
left a comment
AmaadMartin
left a comment
There was a problem hiding this comment.
This refactor is clean: it drops the any and eslint-disable on App.rootAgent, adds the new public types (RunnableRoot, asRunnableRoot, runNodeAsInvocation) to common.ts and index.ts, and uses brand guards, not instanceof. One thing blocks approval: the parallel_worker integration test is red, in code this PR changes. CI run-tests was still running at review time. I did not run any tests.
| ); | ||
|
|
||
| export const rootAgent = new WorkflowAgent({ | ||
| export const rootAgent = new Workflow({ |
There was a problem hiding this comment.
Not a nit. This integration test is red, and this PR changes it.
The aggregate node runs nodeInput.map(...) at tests/integration/workflows/parallel_worker/agent.ts:65. The PR description reports the node receives undefined, so .map throws. The fan-in that fed it an array through WorkflowAgent now feeds undefined when the runner drives the workflow as a node.
model_responses.json is already re-recorded in this PR, and the test still fails. So confirm the node-driven fan-in is correct before you re-record again. A blind re-record can hide a real regression in how parallel worker output reaches the aggregate.
There was a problem hiding this comment.
Thanks — the caution about a blind re-record was the right call, and it turned up something worth fixing. Two parts to this: what the failure actually was, and why you shouldn't have to take my word for it.
The fan-in was not broken. The aggregate did receive a list, with all three slots present and in order. Two of the three slots held undefined. Instrumenting ParallelWorker at the point it assembles results:
PW-DEBUG make_upper_case items= ["SQL","data modeling","database administration"]
results= ["SQL","DATA MODELING","DATABASE ADMINISTRATION"]
PW-DEBUG explain_topic items= ["SQL","DATA MODELING","DATABASE ADMINISTRATION"]
results= [null,null,{"topic":"DATABASE ADMINISTRATION",...}]
The holes came from the model stub, not the fan-in. Two of the three explain_topic requests missed the fixture, RecordReplayModel threw, the agent turn swallowed it into an event with no content, so maybeSetOutput promoted nothing and child.output was undefined. That is the surfacing the harness already warns about in record_replay_model.ts:
This throw is easy to lose: the caller can swallow it and the failure then surfaces far away, as a node reading a property of
undefined.
Why the re-record was legitimate. The old fixture had pinned a race, not a contract. Comparing recorded requests against live ones, workers 0 and 1 had been recorded with no make_upper_case context at all, while worker 2 had all three outputs:
| worker | recorded contents | current contents |
|---|---|---|
0 (SQL) |
topic, find_related_topics ctx, item |
+ make_upper_case ctx (all 3) |
1 (DATA MODELING) |
topic, find_related_topics ctx, item |
+ make_upper_case ctx (all 3) |
2 (DATABASE ADMIN...) |
topic, both ctx blocks, item | unchanged (this one still matched) |
make_upper_case is a predecessor node — it finishes before any explain_topic worker starts — so every worker should see all three of its outputs. At record time two of them hadn't yet, which is why only worker 2's request survived the change. All three are now consistent. So the new fixture encodes more of the contract than the old one, not less.
The part that actually answers your objection. All of the above is still archaeology about one fixture. 55b97048 adds two tests that assert the fan-in where no fixture can reach it: the sample's shape (seed → bounded parallel worker over three items → aggregate) run through the real Runner with a Workflow root, asserting on the list the aggregate is handed rather than on anything the model said. One function worker, one agent worker — the agent case being the one that regressed.
They're mutation-checked rather than merely green: dropping a worker's output in ParallelWorker fails both, and suppressing the agent wrapper's output promotion fails only the agent case. A future re-record can no longer hide a fan-in regression.
CI run-tests has since finished and passed; it was still running when you looked. Full suite locally: 3501 passed, 0 failed.
AmaadMartin
left a comment
AmaadMartin
left a comment
There was a problem hiding this comment.
Re-review at 40f8f3fa. My one finding is resolved. The two new model-free tests in runner_integration_test.ts drive the fan-in through the real Runner and assert one output per item, including the agent-worker case that regressed, so a re-record can no longer hide a fan-in bug. No new any, suppression, or instanceof; RunnableRoot and requireAgent are exported in common.ts.
I am not approving yet. run-tests is still in progress on ubuntu, macOS, and Windows for this commit, so I cannot confirm the parallel_worker integration test now passes. Re-request review once run-tests is green.
AmaadMartin
left a comment
AmaadMartin
left a comment
There was a problem hiding this comment.
Approved at 40f8f3fa. The run-tests matrix that held my last pass is now green on ubuntu, macOS and Windows, which is the direct evidence I was waiting for: the parallel_worker integration test passes, so my finding on tests/integration/workflows/parallel_worker/agent.ts:81 is closed.
I re-verified at this head. RunnableRoot and requireAgent are exported from common.ts (lines 423 and 25), and the diff adds no any, suppression or instanceof — the one any a grep finds is the English word in a doc comment.
One thing before merge: the branch conflicts with main in dev/test/server/adk_api_server_test.ts. That is the only conflicting file, and it is unrelated to this change, so please rebase and resolve it there.
`WorkflowAgent` exists for one reason: `InvocationContext.agent` is non-optional, the runner needs something to put in it, and only an agent fits — so a `Workflow` gets one manufactured for it. adk-python has no such class because it has no such constraint: its field is `BaseAgent | BaseNode | None`, and `_new_invocation_context` passes `agent=self.agent if isinstance(self.agent, BaseAgent) else None`. Nothing else about the adapter is load-bearing. So this makes the field optional. On its own that changes no behaviour — nothing constructs a context without an agent yet — but it is the whole of the blocker, and it is worth landing separately from the runner path that will exploit it. Nineteen sites had to say what they assume. All of them sit in code that only runs *because* an agent is running (an LLM flow, agent transfer, a tool call), so they now go through `requireAgent(ctx)`, which fails by name instead of surfacing as a property access on `undefined` several frames away. The two exceptions are the logging and replay plugins, which observe rather than participate: a logger that throws because there is no agent to name is worse than one that prints nothing, so those fall back instead. `requireAgent` is a free function, not an accessor. A getter is more idiomatic, but a good deal of code — and most of the tests — passes a duck-typed context object, where a getter is simply absent and fails less clearly than the missing agent it is meant to report. Eleven tests found that the direct way. BREAKING CHANGE: `InvocationContext.agent` is now optional. Code reading it outside an agent's own execution must handle `undefined`; inside one, prefer `requireAgent(ctx)`.
…an agent
With `InvocationContext.agent` optional, nothing forces a workflow to be an
agent any more. The runner now keeps the `Workflow` it was handed and drives it
directly; `ic.agent` is simply unset for that invocation, which is what
adk-python does (`agent=self.agent if isinstance(self.agent, BaseAgent) else
None`).
The bridge moves rather than gets rewritten. `WorkflowAgent.runAsyncImpl` was
already the whole of "run a node as an invocation" -- make a root NodeContext,
derive the input from the user message, pump a channel -- so it becomes
`runNodeAsInvocation`, and `WorkflowAgent` shrinks to a four-line delegation
(227 lines to 143). Two callers need that function now, and neither should own
it.
Only two things in the run loop actually differ between a node root and an
agent root, so only those two branch:
- resumption, which resolves an event author against the agent tree and is
meaningless for a node subtree that was never in it;
- the execution call itself, behind `runRoot`.
Everything else -- the before/after run callbacks, `onEvent`, session
persistence, cancellation -- stays on one path. adk-python has a second loop
for this, with a TODO noting that loop lacks tracing and plugins; there is
nothing to lack if there is only one loop.
Losing the wrapper does lose `BaseAgent.runAsync`'s `invoke_agent` span, which
is only acceptable because node execution is traced and plugged in its own
right (#653, #659). Both are now asserted rather than assumed: a workflow run
as a root still produces `invoke_workflow` and `execute_node` spans in the right
tree, and still fires the node hooks. The hooks bracket the workflow node too,
not just the nodes inside it.
BREAKING CHANGE: `Runner.agent` is `BaseAgent | BaseNode`, and is no longer
wrapped when given a `Workflow` -- code reading `runner.agent` and expecting an
agent must narrow. `InvocationContext.agent` is unset while a node root runs.
Removes the adapter outright rather than deprecating it. With the runner able
to drive a node, nothing needed a workflow dressed as an agent, and every seam
that assumed one now takes `RunnableRoot` (`BaseAgent | Workflow`):
- `App` and `AgentLoader` hold the root as given, no longer wrapping;
- the dev graph renderer reads a `Workflow` directly via `isWorkflow`;
- the a2a card describes a workflow as a single `workflow` skill, since it
has nodes rather than sub-agents;
- `cli_run`, the api server and `InMemoryRunner` thread the wider type.
`asRootAgent` becomes `asRunnableRoot`, and keeps taking what an edge takes
rather than narrowing to a root: an agent or a workflow passes through as
itself, and any other node-like value still becomes the single node of a
one-node workflow — the wrapper it built was a `WorkflowAgent`, so only the
thing built changes. `isRunnableRoot` replaces `isRootAgentLike` as the
narrower *discovery* guard, unchanged in what it matches.
`isGraphWorkflowAgent` goes with it; `isWorkflow` covers the same ground. The
a2a card's local `isWorkflowAgent` — which actually meant Loop/Sequential/
Parallel, and sat confusingly next to the real thing — is now
`isCompositeShellAgent`. All 26 samples and the tests build their root with
`new Workflow({...})`, which is the API we want them demonstrating anyway.
`workflow_agent_test.ts` became `run_node_as_invocation_test.ts`, keeping the
plain-text resume and output-once coverage and dropping only the suites that
described the class itself.
KNOWN FAILING, and the reason this is marked WIP: two integration tests. The
cause is identified. `BaseAgent.runAsync` used to build a child context with
`agent: this`, so inside a workflow run `ic.agent` was the WorkflowAgent. Drive
the workflow as a node and there is no agent, so `functions.ts` — which authors
tool events as `requireAgent(invocationContext).name` at four sites — throws for
a `ToolNode` under a node root. `parallel_worker` fails downstream of the same
thing. The fix is to decide what authors a tool event when no agent is running;
the node runner already stamps an author, so these sites likely should not be
asserting one.
Also lost: a workflow can no longer be a sub-agent of a composite agent, since
`subAgents` takes `BaseAgent`. That was the escape hatch the wrapper provided,
and the graph test covering it is removed. Worth a deliberate decision before
this ships.
BREAKING CHANGE: `WorkflowAgent`, `WorkflowAgentConfig` and
`isGraphWorkflowAgent` are removed. Use `Workflow` directly as a root.
…gent runs `functions.ts` authored every event it creates as `requireAgent(ctx).name`. That held while a workflow was wrapped in an agent, because the wrapper put itself in `ic.agent`. Driving the workflow as a node leaves no agent at that level, so a `ToolNode` under a node root threw on an assumption that had simply stopped being true. The node runner already stamps a node's own name onto any event that leaves without an author, so these four sites defer to it instead of asserting. Inside an agent's own turn — every other caller — the agent is set and nothing changes.
The recorded requests stopped matching, and the miss surfaced far from its cause: the harness throws "No recorded model response", the agent turn swallows it into an empty event, and `aggregate` then reads `.topic` off `undefined`. This was the second of the two integration failures this branch carried. What changed is which predecessor outputs a worker sees. `explain_topic` builds its request from the node outputs already committed to the session, and the old fixture caught that mid-flight: workers 0 and 1 were recorded with no `make_upper_case` context at all, while worker 2 had all three. But `make_upper_case` is a predecessor node — it has finished before any worker starts — so every worker should see all three of its outputs, and driving the workflow as a node is what makes every worker actually do so. The old fixture was pinning a race, not a contract. Re-recorded with `npm run record:samples`, which rewrites every sample's fixture; only this one is kept, since the rest were unaffected.
Review raised the right objection to the fixture re-record one commit back: if the only thing watching parallel-worker output is a recorded-response sample, then a re-record can absorb a genuine fan-in regression and the suite stays green. So assert the contract where no fixture can reach it. Both cases run the sample's shape — seed, a bounded parallel worker over three items, an aggregate — through the real `Runner` with a `Workflow` root, and assert on the list the aggregate is actually handed rather than on anything the model said. One uses a function worker, one an agent worker; the agent case is the one that broke, since a worker that produced nothing left `undefined` in the list and the aggregate read a property off it. Checked by mutation, not just by passing: dropping a worker's output in `ParallelWorker` fails both, and suppressing the agent wrapper's output promotion fails only the agent case.
The union in `renderUserInputRequest` was left inline, which Prettier 3.8.4 — the version the lockfile pins, and the one CI runs — breaks onto separate lines. Newer Prettier accepts the inline form, so a local `format:check` against a node_modules that has drifted ahead of the lockfile passes while CI's `run-tests` matrix fails on this one file. No behaviour change; formatting only.
40f8f3f to
8ac3e7e
Compare
AmaadMartin
left a comment
AmaadMartin
left a comment
There was a problem hiding this comment.
Re-approved at 8ac3e7e8. The branch was rebased since my last pass. It is now MERGEABLE, so my earlier conflict note is resolved. My one finding — the red parallel_worker test — stays fixed: the model-free fan-in tests in runner_integration_test.ts survived the rebase and assert one output per item. The diff adds no any, suppression, or instanceof; RunnableRoot, requireAgent, and asRunnableRoot are exported from common.ts and re-exported by index.ts. The only new commit is a Prettier-only format fix. run-tests was still running at review time; it is not a required merge gate.
…ogle#688) * refactor(agents)!: let an invocation have no agent, ahead of node roots `WorkflowAgent` exists for one reason: `InvocationContext.agent` is non-optional, the runner needs something to put in it, and only an agent fits — so a `Workflow` gets one manufactured for it. adk-python has no such class because it has no such constraint: its field is `BaseAgent | BaseNode | None`, and `_new_invocation_context` passes `agent=self.agent if isinstance(self.agent, BaseAgent) else None`. Nothing else about the adapter is load-bearing. So this makes the field optional. On its own that changes no behaviour — nothing constructs a context without an agent yet — but it is the whole of the blocker, and it is worth landing separately from the runner path that will exploit it. Nineteen sites had to say what they assume. All of them sit in code that only runs *because* an agent is running (an LLM flow, agent transfer, a tool call), so they now go through `requireAgent(ctx)`, which fails by name instead of surfacing as a property access on `undefined` several frames away. The two exceptions are the logging and replay plugins, which observe rather than participate: a logger that throws because there is no agent to name is worse than one that prints nothing, so those fall back instead. `requireAgent` is a free function, not an accessor. A getter is more idiomatic, but a good deal of code — and most of the tests — passes a duck-typed context object, where a getter is simply absent and fails less clearly than the missing agent it is meant to report. Eleven tests found that the direct way. BREAKING CHANGE: `InvocationContext.agent` is now optional. Code reading it outside an agent's own execution must handle `undefined`; inside one, prefer `requireAgent(ctx)`. * feat(runner)!: drive a Workflow as a node, instead of dressing it as an agent With `InvocationContext.agent` optional, nothing forces a workflow to be an agent any more. The runner now keeps the `Workflow` it was handed and drives it directly; `ic.agent` is simply unset for that invocation, which is what adk-python does (`agent=self.agent if isinstance(self.agent, BaseAgent) else None`). The bridge moves rather than gets rewritten. `WorkflowAgent.runAsyncImpl` was already the whole of "run a node as an invocation" -- make a root NodeContext, derive the input from the user message, pump a channel -- so it becomes `runNodeAsInvocation`, and `WorkflowAgent` shrinks to a four-line delegation (227 lines to 143). Two callers need that function now, and neither should own it. Only two things in the run loop actually differ between a node root and an agent root, so only those two branch: - resumption, which resolves an event author against the agent tree and is meaningless for a node subtree that was never in it; - the execution call itself, behind `runRoot`. Everything else -- the before/after run callbacks, `onEvent`, session persistence, cancellation -- stays on one path. adk-python has a second loop for this, with a TODO noting that loop lacks tracing and plugins; there is nothing to lack if there is only one loop. Losing the wrapper does lose `BaseAgent.runAsync`'s `invoke_agent` span, which is only acceptable because node execution is traced and plugged in its own right (google#653, google#659). Both are now asserted rather than assumed: a workflow run as a root still produces `invoke_workflow` and `execute_node` spans in the right tree, and still fires the node hooks. The hooks bracket the workflow node too, not just the nodes inside it. BREAKING CHANGE: `Runner.agent` is `BaseAgent | BaseNode`, and is no longer wrapped when given a `Workflow` -- code reading `runner.agent` and expecting an agent must narrow. `InvocationContext.agent` is unset while a node root runs. * feat(workflow)!: remove WorkflowAgent [WIP: 2 integration tests red] Removes the adapter outright rather than deprecating it. With the runner able to drive a node, nothing needed a workflow dressed as an agent, and every seam that assumed one now takes `RunnableRoot` (`BaseAgent | Workflow`): - `App` and `AgentLoader` hold the root as given, no longer wrapping; - the dev graph renderer reads a `Workflow` directly via `isWorkflow`; - the a2a card describes a workflow as a single `workflow` skill, since it has nodes rather than sub-agents; - `cli_run`, the api server and `InMemoryRunner` thread the wider type. `asRootAgent` becomes `asRunnableRoot`, and keeps taking what an edge takes rather than narrowing to a root: an agent or a workflow passes through as itself, and any other node-like value still becomes the single node of a one-node workflow — the wrapper it built was a `WorkflowAgent`, so only the thing built changes. `isRunnableRoot` replaces `isRootAgentLike` as the narrower *discovery* guard, unchanged in what it matches. `isGraphWorkflowAgent` goes with it; `isWorkflow` covers the same ground. The a2a card's local `isWorkflowAgent` — which actually meant Loop/Sequential/ Parallel, and sat confusingly next to the real thing — is now `isCompositeShellAgent`. All 26 samples and the tests build their root with `new Workflow({...})`, which is the API we want them demonstrating anyway. `workflow_agent_test.ts` became `run_node_as_invocation_test.ts`, keeping the plain-text resume and output-once coverage and dropping only the suites that described the class itself. KNOWN FAILING, and the reason this is marked WIP: two integration tests. The cause is identified. `BaseAgent.runAsync` used to build a child context with `agent: this`, so inside a workflow run `ic.agent` was the WorkflowAgent. Drive the workflow as a node and there is no agent, so `functions.ts` — which authors tool events as `requireAgent(invocationContext).name` at four sites — throws for a `ToolNode` under a node root. `parallel_worker` fails downstream of the same thing. The fix is to decide what authors a tool event when no agent is running; the node runner already stamps an author, so these sites likely should not be asserting one. Also lost: a workflow can no longer be a sub-agent of a composite agent, since `subAgents` takes `BaseAgent`. That was the escape hatch the wrapper provided, and the graph test covering it is removed. Worth a deliberate decision before this ships. BREAKING CHANGE: `WorkflowAgent`, `WorkflowAgentConfig` and `isGraphWorkflowAgent` are removed. Use `Workflow` directly as a root. * fix(agents): let a tool event take its author from the node when no agent runs `functions.ts` authored every event it creates as `requireAgent(ctx).name`. That held while a workflow was wrapped in an agent, because the wrapper put itself in `ic.agent`. Driving the workflow as a node leaves no agent at that level, so a `ToolNode` under a node root threw on an assumption that had simply stopped being true. The node runner already stamps a node's own name onto any event that leaves without an author, so these four sites defer to it instead of asserting. Inside an agent's own turn — every other caller — the agent is set and nothing changes. * test(workflows): re-record the parallel_worker fixture The recorded requests stopped matching, and the miss surfaced far from its cause: the harness throws "No recorded model response", the agent turn swallows it into an empty event, and `aggregate` then reads `.topic` off `undefined`. This was the second of the two integration failures this branch carried. What changed is which predecessor outputs a worker sees. `explain_topic` builds its request from the node outputs already committed to the session, and the old fixture caught that mid-flight: workers 0 and 1 were recorded with no `make_upper_case` context at all, while worker 2 had all three. But `make_upper_case` is a predecessor node — it has finished before any worker starts — so every worker should see all three of its outputs, and driving the workflow as a node is what makes every worker actually do so. The old fixture was pinning a race, not a contract. Re-recorded with `npm run record:samples`, which rewrites every sample's fixture; only this one is kept, since the rest were unaffected. * test(workflow): pin the ParallelWorker fan-in without a model Review raised the right objection to the fixture re-record one commit back: if the only thing watching parallel-worker output is a recorded-response sample, then a re-record can absorb a genuine fan-in regression and the suite stays green. So assert the contract where no fixture can reach it. Both cases run the sample's shape — seed, a bounded parallel worker over three items, an aggregate — through the real `Runner` with a `Workflow` root, and assert on the list the aggregate is actually handed rather than on anything the model said. One uses a function worker, one an agent worker; the agent case is the one that broke, since a worker that produced nothing left `undefined` in the list and the aggregate read a property off it. Checked by mutation, not just by passing: dropping a worker's output in `ParallelWorker` fails both, and suppressing the agent wrapper's output promotion fails only the agent case. * style(cli): wrap the auth-scheme cast the way the pinned Prettier wants The union in `renderUserInputRequest` was left inline, which Prettier 3.8.4 — the version the lockfile pins, and the one CI runs — breaks onto separate lines. Newer Prettier accepts the inline form, so a local `format:check` against a node_modules that has drifted ahead of the lockfile passes while CI's `run-tests` matrix fails on this one file. No behaviour change; formatting only.
2 participants
Link to Issue or Description of Change
Problem:
WorkflowAgentexisted for exactly one reason, and it was not a good one:InvocationContext.agentwas non-optional, the runner needed something to put there, and only an agent fit — so aWorkflowhad one manufactured for it. The class implemented no agent behaviour: no callbacks, no sub-agents, no transfer, and arunLiveImplthat only threw. adk-python has no such class because it has no such constraint.Solution, in four commits:
InvocationContext.agentbecomes optional. 19 sites across 11 files had to say what they assume; all sit in code that only runs because an agent is running, so they go through a newrequireAgent(ctx)that fails by name. The logging and replay plugins fall back instead — a logger that throws because there is no agent to name is worse than one that prints nothing. This mirrors Python, whose field isBaseAgent | BaseNode | Noneand which passesNoneon the node path.The runner drives a node.
WorkflowAgent.runAsyncImplwas already "run a node as an invocation", so it becamerunNodeAsInvocation. Only two things in the run loop differ for a node root — resumption (which resolves an author against an agent tree a node was never in) and the execution call. Everything else stays on one path. Python has a second loop here, with a TODO that it lacks tracing and plugins; there is nothing to lack if there is only one loop.WorkflowAgentis removed. Every seam that assumed an agent now takesRunnableRoot(BaseAgent | Workflow):App,AgentLoader, the dev graph renderer, the a2a card,cli_run, the api server,InMemoryRunner. All 26 samples build their root withnew Workflow({...})— the API we want demonstrated anyway.Tool events take their author from the node when no agent is running.
Two things worth a reviewer's attention:
subAgentstakesBaseAgent, and the wrapper was the escape hatch. This is the caveat Python's own deprecation message names. I removed the graph test that covered it rather than fake it. If nesting matters, the answer is wideningsubAgents— not restoring the adapter.BaseAgent.runAsync'sinvoke_agentspan, which is only acceptable because feat(workflow): trace workflow and node execution with OpenTelemetry #653 and feat(plugins): add before/after node callbacks #659 traced and plugged node execution. There are now tests that a root workflow still emitsinvoke_workflow/execute_nodein the right tree and still fires the node hooks.Known failing
tests/integration/workflows/parallel_worker— the aggregate node receives undefined items.This is the fixture-shift mode from #659, not a logic error: the harness matches recorded model responses by a fingerprint over request contents, and removing the wrapper legitimately changes the conversation a worker agent sees. The likely resolution is re-recording with
RECORD_MODEL_RESPONSES=1, which needs a live key I do not have. Worth one reviewer look to confirm the contents change is intended before re-recording — re-recording hides a real regression just as easily as it fixes a stale fixture.Testing Plan
workflow_agent_test.tsbecamerun_node_as_invocation_test.ts, keeping the plain-text-resume and output-once coverage from #669 and dropping only the suites that described the removed class.Checklist
Additional context
BREAKING, and squarely for the 2.0 in #629:
WorkflowAgent,WorkflowAgentConfigandisGraphWorkflowAgentare gone;InvocationContext.agentis optional;Runner.agentisRunnableRoot.Also renamed the a2a card's local
isWorkflowAgent— which actually meant Loop/Sequential/Parallel and sat next to the real guard — toisCompositeShellAgent.Design notes:
adk-ts-runner-drives-nodes-design.mdin the session artifacts.🤖 Generated with CloudCode
Session:
ses_00b1fb6baffeIv7P3GOZ0QovmR