I agree with Robert that the current implementation is not good and should
be ripped out ASAP. However, I see this effort as complementary to Will's
refactor, not as a dependency. We should first add a layer of abstraction
between the business logic in Polaris and the task execution -- once that's
Thanks for the async task proposal. I think it's the right direction
for async light tasks. Meanwhile, we will still need other models:
1. A scalable way to execute synchronous tasks
2. A scalable way to execute heavy async tasks, e.g., table maintenance
tasks.
The delegation service[1] is a good
I'm fine with the plan although I think we should probably change step 4 to
allow both the current implementation and the new implementation to exist at
the same time with a flag for switching over to the new task implementation.
While the new implementation may be much better, it is a pretty si
>
> Considering the current issues, I don't think it's worth the effort to
> keep the current implementation.
It seems risky to me to not support the current implementation at least for
the period where the new tasks implementation is unstable.
Bests,
William
On Tue, Jul 29, 2025 at 3:49 AM Rob
Hi,
(starting w/ a recap for everybody watching this thread)
The goal of this is to have a mechanism to guarantee the _eventual_
execution of a task. That may happen immediately on the same node or
at a later time on another node.
This particular "async reliable tasks" is to ensure that tasks run
Hey Robert!
Thank you for the draft PR.
I have taken a look and the general approach seems good to me.
However, one of my concerns would be the timeline to deliver this new
task framework refactoring as this could be intrusive due to the scope
of the change.
What do you plan as the ETA for deliver
Hi,
As discussed on the Polaris Community Sync today, we're aligned that
the current tasks handling needs some refactoring.
This proposal focuses on the "eventual execution" of a task.
Implementations for would follow.
The "Delegation Service" [1] proposal focuses on the execution of
tasks "outs
Yes, each "task behavior" has an ID. I've chosen the term "task
behavior" over "type", because it doesn't only define "what's done" but
also "when" it's done (delay) and "how it behaves" (retries on failures).
On 14.05.25 04:25, Adnan Hemani wrote:
Hi Robert,
Firstly, thanks for this document
Hi Robert,
Firstly, thanks for this document. One quick question: is the `behavior ID`
basically the task type? This part was slightly unclear to me.
Best,
Adnan Hemani
> On May 9, 2025, at 6:07 AM, Robert Stupp wrote:
>
> Hi,
>
> Polaris is a service, which has to eventually perform operati
Hi Robert,
Each individual task should also be executed only once
If the plan is to have something similar to Nessie tasks management, I do
not think "only once" execution is guaranteed there. What is guaranteed in
Nessie is that at most one "result" is produced... However, if a task has
side ef
Hi,
Polaris is a service, which has to eventually perform operations
asynchronously. Polaris is also meant to be backed by multiple server
instances (think: high-availability & load-balancing setups).
During runtime, things can go sideways in many ways. Server instances
may crash, be killed
11 matches
Mail list logo
