[Proposal] Workflow building block and engine

In what area(s)?
/area runtime
What?
This document proposes that the Dapr runtime be extended to include a new workflow building block. This building block, in combination with a lightweight, portable, workflow engine will enable developers to express workflows as code that can be executed, interacted with, monitored, and debugged using the Dapr runtime.
Why?
Many complex business processes are well modeled as a workflow - a set of steps needing to be orchestrated that require resiliency and guarantee completion (success or failure are both completions). To build such workflows, developers are often faced with needing to solve a host of complex problems, including (but not limited to):

Scheduling
Lifecycle management
State storage
Monitoring and debugging
Resiliency
Failure handling mechanisms

Based on available data, it is clear that workflows are quite popular; at the time of this writing, the number of daily executions for hosted workflows and their tasks is in the billions per day across tens of thousands of Azure subscriptions.
What is a workflow?
A workflow, for the purpose of this proposal, is defined as application logic that defines a business process or data flow that:

Has a specific, pre-defined, deterministic lifecycle (e.g Pending -> Running -> [Completed | Failed | Terminated])
Is guaranteed to complete
Is durable (i.e completion in the face of transient errors)
Can be scheduled to start or execute steps at or after some future time
Can be paused and resumed (explicitly or implicitly)
Can execute portions of the workflow in serial or parallel
Can be directly addressed by external agents (i.e an instance of the workflow can be interacted with directly - paused, resumed, queried, etc.)
May be versioned
May be stateful
May create new sub-workflows and optionally wait for those to complete before progressing
May rely on external components to perform its job (i.e HTTPS API calls, pub/sub message queues, etc.)

Why Dapr?
Dapr already contains many of the building blocks required to provide reliability, scalability, and durability to the execution of workflows. Building such an engine inside Dapr, and providing the necessary building blocks will help to increase developer productivity through re-usability of existing features and independence from the underlying execution mechanism thereby increasing portability.
In addition to the built-in execution engine, Dapr can provide a consistent programming interface for interacting with third-party workflow execution systems (i.e AWS SWF, Apache Camel, Drools) for those who are already using these tools. Thereby providing a standardized interface for working with both external workflows as well as those running inside Dapr.
Proposal
High-level overview of changes
We propose that the following features / capabilities be added to the Dapr runtime:

A new "workflow" building block
A portable, lightweight, workflow engine embedded into the Dapr sidecar capable of supporting long-running, resilient, and durable workflows through Dapr's building blocks
An expressive, developer-friendly, programming model for building workflows as code
Support for containerized, declarative, workflows (such as the CNCF Serverless Workflow specification)
Extensions to the Dapr dashboard for monitoring / managing workflow execution
APIs for interacting with workflows

The Workflow building block
As mentioned before, this proposal includes the addition of a new workflow building block. Like most of the other Dapr building blocks (state stores, pubsub, etc.) the workflow building block will consist of two primary things:

A pluggable component model for integrating various workflow engines
A set of APIs for managing workflows (start, schedule, pause, resume, cancel)

Similar to the built-in support for actors, we also propose implementing a built-in runtime for workflows (see the DTFx-go engine described in the next section). Unlike actors, the workflow runtime component can be swapped out with an alternate implementation. If developers want to work with other workflow engines, such as externally hosted workflow services like Azure Logic Apps, AWS Step Functions, or Temporal.io, they can do so with alternate community-contributed workflow components.
The value of this building block for vendors is that workflows supported by their platforms can be exposed as APIs with support for HTTP and the Dapr SDKs. The less visible but benefits of mTLS, distributed tracing, etc. will also be available. Various abstractions, such as async HTTP polling, can also be supported via Dapr without the workflow vendor needing to implement it themselves.
Introducing DTFx-go
We propose adding a lightweight, portable, embedded workflow engine (DTFx-go) in the Dapr sidecar that leverages existing Dapr components, including actors and state storage, in its underlying implementation. By being lightweight and portable developers will be able to execute workflows that run inside DFTx-go locally as well as in production with minimal overhead; this enhances the developer experience by integrating workflows with the existing Dapr development model that users enjoy.
The new engine will be written in Go and inspired by the existing Durable Task Framework (DTFx) engine. We’ll call this new version of the framework DTFx-go to distinguish it from the .NET implementation (which is not part of this proposal) and it will exist as an open-source project with a permissive, e.g., Apache 2.0, license so that it remains compatible as a dependency for CNCF projects. Note that it’s important to ensure this engine remains lightweight so as not to noticeably increase the size of the Dapr sidecar.
Importantly, DTFx-go will not be exposed to the application layer. Rather, the Dapr sidecar will expose DTFx-go functionality over a gRPC stream. The Dapr sidecar will not execute any app-specific workflow logic or load any declarative workflow documents. Instead, app containers will be responsible for hosting the actual workflow logic. The Dapr sidecar can send and receive workflow commands over gRPC to and from connected app’s workflow logic, execute commands on behalf of the workflow (service invocation, invoking bindings, etc.). Other concerns such as activation, scale-out, and state persistence will be handled by internally managed actors. More details on all of this will be discussed in subsequent sections.
Execution, scheduling and resilience
Internally, Dapr workflow instances will be implemented as actors. Actors drive workflow execution by communicating with the workflow SDK over a gRPC stream. By using actors, the problem of placement and scalability are already solved for us.

The execution of individual workflows will be triggered using actor reminders as they are both persistent and durable (two critical features of workflows). If a container or node crashes during a workflow’s execution, the actor’s reminder will ensure it gets activated again and resumes where it left off (using state storage to provide durability, see below).
To prevent a workflow from blocking (unintentionally) each workflow will be composed of two separate actor components, one acting as the scheduler / coordinator and the other performing the actual work (calling API services, performing computation, etc.).

Storage of state and durability
In order for a workflow execution to reliably complete in the face of transient errors, it must be durable -- meaning that it is able to store data at checkpoints as it makes progress. To achieve this, workflow executions will rely on Dapr's state storage to provide stable storage such that the workflow can be safely resumed from a known-state in the event that it is explicitly paused or a step is prematurely terminated (system failure, lack of resources, etc.).
Workflows as code
The term "workflow as code" refers to the implementation of a workflow’s logic using general purpose programming languages. "Workflow as code" is used in a growing number of modern workflow frameworks, such as  Azure Durable Functions, Temporal.io, and Prefect (Orion). The advantage of this approach is its developer-friendliness. Developers can use a programming language that they already know (no need to learn a new DSL or YAML schema), they have access to the language’s standard libraries, can build their own libraries and abstractions, can use debuggers and examine local variables, and can even write unit tests for their workflows just like they would any other part of their application logic.
The Dapr SDK will internally communicate with the DTFx-go gRPC endpoint in the Dapr sidecar to receive new workflow events and send new workflow commands, but these protocol details will be hidden from the developer. Due to the complexities of the workflow protocol, we are not proposing any HTTP API for the runtime aspect of this feature.
Support for declarative workflows
We expect workflows as code to be very popular for developers because working with code is both very natural for developers and is much more expressive and flexible compared to declarative workflow modeling languages. In spite of this, there will still be users who will prefer or require workflows to be declarative. To support this, we propose building an experience for declarative workflows as a layer on top of the "workflow as code" foundation. A variety of declarative workflows could be supported in this way. For example, this model could be used to support the AWS Step Functions workflow syntax, the Azure Logic Apps workflow syntax, or even the Google Cloud Workflow syntax. However, for the purpose of this proposal, we’ll focus on what it would look like to support the CNCF Serverless Workflow specification. Note, however, that the proposed model could be used to support any number of declarative multiple workflow schemas.
CNCF Serverless Workflows
Serverless Workflow (SLWF) consists of an open-source standards-based DSL and dev tools for authoring and validating workflows in either JSON or YAML. SLWF was specifically selected for this proposal because it represents a cloud native and industry standard way to author workflows. There are a set of already existing open-source tools for generating and validating these workflows that can be adopted by the community. It’s also an ideal fit for Dapr since it’s under the CNCF umbrella (currently as a sandbox project). This proposal would support the SLWF project by providing it with a lightweight, portable runtime – i.e., the Dapr sidecar.
Hosting Serverless Workflows
In this proposal, we use the Dapr SDKs to build a new, portable SLWF runtime that leverages the Dapr sidecar. Most likely it is implemented as a reusable container image and supports loading workflow definition files from Dapr state stores (the exact details need to be worked out). Note that the Dapr sidecar doesn’t load any workflow definitions. Rather, the sidecar simply drives the execution of the workflows, leaving all other details to the application layer.
API
Start Workflow API
HTTP / gRPC
Developers can start workflow instances by issuing an HTTP (or gRPC) API call to the Dapr sidecar:
POST http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}/start
Workflows are assumed to have a type that is identified by the {workflowType} parameter. Each workflow instance must also be created with a unique {instanceId} value. The payload of the request is the input of the workflow. If a workflow instance with this ID already exists, this call will fail with an HTTP 409 Conflict.
To support asynchronous HTTP polling pattern by HTTP clients, this API will return an HTTP 202 Accepted response with a Location header containing a URL that can be used to get the status of the workflow (see further below). When the workflow completes, this endpoint will return an HTTP 200 response. If it fails, the endpoint can return a 4XX or 5XX error HTTP response code. Some of these details may need to be configurable since there is no universal protocol for async API handling.
Input bindings
For certain types of automation scenarios, it can be useful to trigger new instances of workflows directly from Dapr input bindings. For example, it may be useful to trigger a workflow in response to a tweet from a particular user account using the Twitter input binding. Another example is starting a new workflow in response to a Kubernetes event, like a deployment creation event.
The instance ID and input payload for the workflow depends on the configuration of the input binding. For example, a user may want to use a Tweet’s unique ID or the name of the Kubernetes deployment as the instance ID.
Pub/Sub
Workflows can also be started directly from pub/sub events, similar to the proposal for Actor pub/sub. Configuration on the pub/sub topic can be used to identify an appropriate instance ID and input payload to use for initializing the workflow. In the simplest case, the source + ID of the cloud event message can be used as the workflow’s instance ID.
Terminate workflow API
HTTP / gRPC
Workflow instances can also be terminated using an explicit API call.
POST http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}/terminate
Workflow termination is primarily an operation that a service operator takes if a particular business process needs to be cancelled, or if a problem with the workflow requires it to be stopped to mitigate impact to other services.
If a payload is included in the POST request, it will be saved as the output of the workflow instance.
Raise Event API
Workflows are especially useful when they can wait for and be driven by external events. For example, a workflow could subscribe to events from a pubsub topic as shown in the Phone Verification sample. However, this capability shouldn’t be limited to pub/sub events.
HTTP / gRPC
An API should exist for publishing events directly to a workflow instance:
POST http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}/raiseEvent
The result of the "raise event" API is an HTTP 202 Accepted, indicating that the event was received but possibly not yet processed. A workflow can consume an external event using the waitForExternalEvent SDK method.
Get workflow metadata API
HTTP / gRPC
Users can fetch the metadata of a workflow instance using an explicit API call.
GET http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}
The result of this call is workflow instance metadata, such as its start time, runtime status, completion time (if completed), and custom or runtime-specific status. If supported by the target runtime, workflow inputs and outputs can also be fetched using the query API.
Purge workflow metadata API
Users can delete all state associated with a workflow using the following API:
DELETE http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}
When using the embedded workflow component, this will delete all state stored by the workflow’s underlying actor(s).
Footnotes and Examples
Example 1: Bank transaction
In this example, the workflow is implemented as a JavaScript generator function. The "bank1" and "bank2" parameters are Microservice apps that use Dapr, each of which expose "withdraw" and "deposit" APIs. The Dapr APIs available to the workflow come from the context parameter object and return a "task" which effectively the same as a Promise. Calling yield on the task causes the workflow to durably checkpoint its progress and wait until Dapr responds with the output of the service method. The value of the task is the service invocation result. If any service method call fails with an error, the error is surfaced as a raised JavaScript error that can be caught using normal try/catch syntax. This code can also be debugged using a Node.js debugger.
Note that the details around how code is written will vary depending on the language. For example, a C# SDK would allow developers to use async/await instead of yield. Regardless of the language details, the core capabilities will be the same across all languages.
import { DaprWorkflowClient, DaprWorkflowContext, HttpMethod } from "dapr-client";

const daprHost = process.env.DAPR_HOST || "<IP_ADDRESS>"; // Dapr sidecar host

const daprPort = process.env.DAPR_WF_PORT || "50001";  // Dapr sidecar port for workflow

const workflowClient = new DaprWorkflowClient(daprHost, daprPort);

// Funds transfer workflow which receives a context object from Dapr and an input
workflowClient.addWorkflow('transfer-funds-workflow', function*(context: DaprWorkflowContext, op: any) {
    // use built-in methods for generating psuedo-random data in a workflow-safe way
    const transactionId = context.createV5uuid();

    // try to withdraw funds from the source account.
    const success = yield context.invoker.invoke("bank1", "withdraw", HttpMethod.POST, {
        srcAccount: op.srcAccount,
        amount: op.amount,
        transactionId
    });

    if (!success.success) {
        return "Insufficient funds";
    }

    try {
        // attempt to deposit into the dest account, which is part of a separate microservice app
        yield context.invoker.invoke("bank2", "deposit", HttpMethod.POST, {
            destAccount: op.destAccount,
            amount: op.amount,
            transactionId
        });
        return "success";
    } catch {
        // compensate for failures by returning the funds to the original account
        yield context.invoker.invoke("bank1", "deposit", HttpMethod.POST, {
            destAccount: op.srcAccount,
            amount: op.amount,
            transactionId
        });
        return "failure";
    }
});

// Call start() to start processing workflow events
workflowClient.start();

Example 2: Phone Verification
Here’s another sample that shows how a developer might build an SMS phone verification workflow. The workflow receives some user’s phone number, creates a challenge code, delivers the challenge code to the user’s SMS number, and waits for the user to respond with the correct challenge code.
The important takeaway is that the end-to-end workflow can be represented as a single, easy-to-understand function. Rather than relying directly on actors to hold state explicitly, state (such as the challenge code) can simply be stored in local variables, drastically reducing the overall code complexity and making the solution easily unit testable.
import { DaprWorkflowClient, DaprWorkflowContext, HttpMethod } from "dapr-client";

const daprHost = process.env.DAPR_HOST || "<IP_ADDRESS>"; // Dapr sidecar host
const daprPort = process.env.DAPR_WF_PORT || "50001";  // Dapr sidecar port for workflow
const workflowClient = new DaprWorkflowClient(daprHost, daprPort);

// Phone number verification workflow which receives a context object from Dapr and an input
workflowClient.addWorkflow('phone-verification', function*(context: DaprWorkflowContext, phoneNumber: string) {

    // Create a challenge code and send a notification to the user's phone
    const challengeCode = yield context.invoker.invoke("authService", "createSmsChallenge", HttpMethod.POST, {
        phoneNumber
    });

    // Schedule a durable timer for some future date (e.g. 5 minutes or perhaps even 24 hours from now)
    const expirationTimer = context.createTimer(challengeCode.expiration);

    // The user gets three tries to respond with the right challenge code
    let authenticated = false;

    for (let i = 0; i <= 3; i++) {
        // subscribe to the event representing the user challenge response
        const responseTask = context.pubsub.subscribeOnce("my-pubsub-component", "sms-challenge-topic");

        // block the workflow until either the timeout expires or we get a response event
        const winner = yield context.whenAny([expirationTimer, responseTask]);

        if (winner === expirationTimer) {
            break; // timeout expired
        }

        // we get a pubsub event with the user's SMS challenge response
        if (responseTask.result.data.challengeNumber === challengeCode.number) {
            authenticated = true; // challenge verified!
            expirationTimer.cancel();
            break;
        }
    }

    // the return value is available as part of the workflow status. Alternatively, we could send a notification.
    return authenticated;
});

// Call listen() to start processing workflow events
workflowClient.listen();

Example 3: Declarative workflow for monitoring patient vitals
The following is an example of a very simple SLWF workflow definition that listens on three different event types and invokes a function depending on which event was received.
{
    "id": "monitorPatientVitalsWorkflow",
    "version": "1.0",
    "name": "Monitor Patient Vitals Workflow",
    "states": [
      {
        "name": "Monitor Vitals",
        "type": "event",
        "onEvents": [
          {
            "eventRefs": [
              "High Body Temp Event",
              "High Blood Pressure Event"
            ],
            "actions": [{"functionRef": "Invoke Dispatch Nurse Function"}]
          },
          {
            "eventRefs": ["High Respiration Rate Event"],
            "actions": [{"functionRef": "Invoke Dispatch Pulmonologist Function"}]
          }
        ],
        "end": true
      }
    ],
    "functions": "file://my/services/asyncapipatientservicedefs.json",
    "events": "file://my/events/patientcloudeventsdefs.yml"
}

The functions defined in this workflow would map to Dapr service invocation calls. Similarly, the events would map to incoming Dapr pub/sub events. Behind the scenes, the runtime (which is built using the Dapr SDK APIs mentioned previously) handles the communication with the Dapr sidecar, which in turn manages the checkpointing of state and recovery semantics for the workflows.

cc @beiwei30 @daixiang0 @cvictory @msfussell @Forrest-zhao @paulyuk

(Fixed the placement image, there were previously two duplicate Actor entities)

Workflows are one of my favorite areas for actors so I'm happy to see them here :) Quick question though.
Can you describe more on how you're planning on using reminders? Are they just to let users start a workflow on a given period? Or, are we going to be registering reminders for every workflow step and then deleting them when they are done?
If it's the latter, that could end up being a lot of reminders. If that's the case we should call out that we'll use reminder partitioning as I think it'd be likely that we'd hit the tipping point for reminder scaling (which does vary based on the underlying statestore).

Looking forward to this! Initial Qs...
The description of DTFx-go reads "lightweight, portable, embedded workflow engine (DTFx-go) in the Dapr sidecar"

Does this mean that you get a workflow engine out-of-the-box, by default, in any environment that is running Dapr? So I don't have to select SLWF, or temporal.io etc?

Do I have to specify a state-management component to provide the state store behind the OOTB workflow engine (DTFx-go) ? i.e. With Dapr actors, I must define a state-management component to back the actor state.

Other thoughts

Is it wise to call this implementation DTFx-go? I'm specifically talking about the DTFx bit. I ask because DTFx brings a bunch of baggage/concepts/knowledge. Such as TaskHub, and the various storage Providers for the TaskHub. Could this introduce confusion, as customers may expect a degree of interoperability with DTFx?! For example. I had the initial thought that this might be compatible with DF Monitor utility - but it won't as I don't recognise there being a TaskHub concept in DTFx-go proposal thus far.

Can you describe more on how you're planning on using reminders? Are they just to let users start a workflow on a given period? Or, are we going to be registering reminders for every workflow step and then deleting them when they are done?
If it's the latter, that could end up being a lot of reminders. If that's the case we should call out that we'll use reminder partitioning as I think it'd be likely that we'd hit the tipping point for reminder scaling (which does vary based on the underlying statestore).

The exact details are still being ironed out, but it's essentially a variation of the latter - i.e., one active reminder per workflow instance (though not necessarily per action). I agree that leveraging the reminder partitioning work is the right way to ensure this remains scalable. We need to do a bit more research here to figure out the details.

Does this mean that you get a workflow engine out-of-the-box, by default, in any environment that is running Dapr? So I don't have to select SLWF, or temporal.io etc?

Correct - the embedded engine will be the "out of the box" option for anyone that doesn't want to install additional infrastructure into their cluster. We want external workflow services to be supported by the building block (we expect many will prefer to use workflow systems that they already know and love), but not required.

Do I have to specify a state-management component to provide the state store behind the OOTB workflow engine (DTFx-go) ? i.e. With Dapr actors, I must define a state-management component to back the actor state.

Yes, this is essentially a programming model that sits on top of actors, so you'll still need to configure a state store that supports actors.

Is it wise to call this implementation DTFx-go? I'm specifically talking about the DTFx bit. I ask because DTFx brings a bunch of baggage/concepts/knowledge. Such as TaskHub, and the various storage Providers for the TaskHub. Could this introduce confusion, as customers may expect a degree of interoperability with DTFx?! For example.

I'm not too worried about confusion because DTFx-go is just an implementation detail that most users won't know or care about. Users of Dapr will simply be presented with "Dapr Workflow" as a concept and we wouldn't necessarily expose the same extensibility or tooling. The existing DTFx isn't super well-known outside of Azure Functions or internal Microsoft circles, so I'm assuming there won't be a lot of opportunity for confusion even for folks who care to look at the implementation details.
FWIW, the DTFx-go backend storage provider will one built specifically for storing state and load balancing via the Dapr Actors infrastructure.

Assuming DF Monitor is NOT compatible, it might be worth lifting some of the concepts from DF Monitor and hosting similar concepts in the Dapr Dashboard to help with the observability and management of workflows.

Yes, integration with the Dapr Dashboard is definitely part of the plan.

@cgillum got it thanks.
Suggestion : It might be worth updating the section Storage of state and durability to be a little more explicit that an “Actor compatible” dapr state store component is required in order to light-up the embedded engine.

Any indication if workflows must be deterministic, due to replay semantics?

Very interesting proposal... look forward to seeing it progress!
I wonder about the feasibility of a pluggable execution layer... certainly you can define contracts for required integration points (surfacing metadata, lifecycle management, state hydration, etc.) and implement, say, SLWF on top of that from scratch.
How would you envision that working for an existing runtime like AWS Step Functions or Temporal.io, which aren't necessarily built to plug into those abstractions, or in general to be driven "from the outside"?
For this to work, it seems like you would need a "workflow internals spec" to define the required integration points... and then need vendors to implement it. Or do I misunderstand?

Any indication if workflows must be deterministic, due to replay semantics?

Yes, thanks @olitomlinson for calling this out. @johnewart I think we need to update the description above to reflect this important coding constraint.

For this to work, it seems like you would need a "workflow internals spec" to define the required integration points... and then need vendors to implement it. Or do I misunderstand?

@jplane I wonder if there might be a slight misunderstanding. We're not proposing that the internal execution engine should support plugging in existing WF runtimes like Step Functions or Temporal.io. That would be a really hard problem to solve, as you suggested, and may not be in everyone's best interest. Rather, we're proposing two specific stories for how other workflow languages and/or runtimes can be pulled in:

The WF building block contract (i.e. the HTTP APIs mentioned) can be used to interface with externally hosted workflow services, similar to how the state stores and pubsub building blocks work. In this case, the built-in engine isn't used at all.
Things like SLWF (or other declarative workflow languages, including the AWS Step Functions spec - i.e. the Amazon States Language) can be supported by implementing a new runtime layer on top of the built-in engine's programming model. In this case, we're using the Dapr workflow engine and not any other existing engine.

The latter point (2) isn't strictly "pluggable extensibility", per-se, but more of a model for how developers could contribute their own declarative workflow runtimes that internally rely on the Dapr Workflow built-in engine. It's very similar to the POC SLWF prototype you and I built some time back on top of Durable Functions - the existing Durable engine was used to implement scheduling, durability, etc. and a layer on top was built to interpret the SLWF markup and interface with the Durable APIs.
I hope that makes sense. I can try to clarify further if it's still confusing.

Thx @cgillum for the explanation... that makes sense now.
I really like the direction... be ruthlessly sparse with the engine programming model, and let a thousand higher-order models bloom on top of it. Nice!
Not 100% sold on the BYOruntime sales pitch just yet... the Dapr WF engine's semantics will become a pseudo-standard, so anything that does state management, work scheduling, etc. differently may not be seamlessly swappable behind the building block contract (or, at least, might violate The Principle of Least Surprise for the unsuspecting caller). I see the appeal of swappable runtimes... just wondering about real-world challenges, too.

the Dapr WF engine's semantics will become a pseudo-standard

The goal is to make the Dapr WF APIs (and all Dapr APIs in general) a standard and via work that is on-going on our API-spec special interest group.

so anything that does state management, work scheduling, etc. differently may not be seamlessly swappable behind the building block contract (or, at least, might violate The Principle of Least Surprise for the unsuspecting caller). I see the appeal of swappable runtimes... just wondering about real-world challenges, too.

I agree with what you're saying here, but I actually think its valid. In this case, we certainly want to encourage users to choose the default, tested and optimized path of least resistance yet open the door for other runtimes if there are special considerations to be made.

Excited to finally see this being discussed! Which means I get to learn more about it myself :-)
I'm a bit unsure about the capabilities of the "worker" actor. Is it correct to say that all context.invoker.invoke commands in the sample code translate to an operation in the worker? Is it also safe to say the worker actor exists simply to provide a framework-compatible means of performing I/O, which is otherwise not allowed directly in the user code? Thanks!

Is it correct to say that all context.invoker.invoke commands in the sample code translate to an operation in the worker?

Behind the scenes, yes. This actor is designed to do any work that may take an indeterminate amount of time to complete, like service invocation. This frees up the scheduler actor to do other work, like respond to queries.

Is it also safe to say the worker actor exists simply to provide a framework-compatible means of performing I/O, which is otherwise not allowed directly in the user code?

Not necessarily. Technically, the scheduler actor could do all the I/O on behalf of the workflow code. The worker actor is really only for potentially long-running I/O, to keep the scheduler actor from getting blocked for too long (actors are single threaded). We may have the scheduler actor do other types of I/O directly, like publishing pub/sub messages.

Instead, app containers will be responsible for hosting the actual workflow logic.

Can a single container image host multiple different types of workflow? Any theoretical limits you are aware of at this point?

Can a container image that hosts a workflow also invoke endpoints hosted in that same container image?

Can a single container image host multiple different types of workflow? Any theoretical limits you are aware of at this point?

Yes, absolutely. The code samples above show only one call to workflowClient.addWorkflow(...), but multiple calls can be made to register multiple workflows from the same app.

Can a container image that hosts a workflow also invoke endpoints hosted in that same container image?

Yes, a single container image/app can host workflows and service invocation endpoints together, so if the context.invoker.invoke call targets the currently running Dapr app, then the same container image would be the one that receives the service invocation request.

Is it correct to say that all context.invoker.invoke commands in the sample code translate to an operation in the worker?

Behind the scenes, yes. This actor is designed to do any work that may take an indeterminate amount of time to complete, like service invocation. This frees up the scheduler actor to do other work, like respond to queries.

Is it also safe to say the worker actor exists simply to provide a framework-compatible means of performing I/O, which is otherwise not allowed directly in the user code?

Not necessarily. Technically, the scheduler actor could do all the I/O on behalf of the workflow code. The worker actor is really only for potentially long-running I/O, to keep the scheduler actor from getting blocked for too long (actors are single threaded). We may have the scheduler actor do other types of I/O directly, like publishing pub/sub messages.

Thanks, this makes sense. So I suppose that there will be a pre-determined mapping that makes certain APIs, like context.invoker.invoke always go onto the worker actor, while other more constrained APIs will go to the scheduler.
Something else that stood out to be is that I don't see any reference to context.invoker.invoke in the API listing of the original post. Will that be part of a different proposal? I'm interested in understanding what other methods and utilities can be accessed from the DaprWorkflowContext object :-) .

The original post goes into the details of the workflow building block APIs, which describe how existing app code can interact with Dapr workflows, whether self-hosted or externally hosted.  APIs for implementing self-hosted workflows like context.invoker.invoke aren't currently enumerated. Right now, we're expecting to cover core Dapr APIs, like service invocation, pub/sub, bindings, etc. but will likely have a few others as well. Exact details TBD.

The context object — is part of the Workflow SDK, right?
User code must use this context object from the SDK? There is no option to use a HTTP API?
If what I’ve said is correct, this wouldn’t align with the dapr principle of being language agnostic, right? Might that cause a rub?

User code must use this context object from the SDK? There is no option to use a HTTP API?

Correct, and @johnewart mentioned this in the original post in the "Workflow as code" section:

The Dapr SDK will internally communicate with the DTFx-go gRPC endpoint in the Dapr sidecar to receive new workflow events and send new workflow commands, but these protocol details will be hidden from the developer. Due to the complexities of the workflow protocol, we are not proposing any HTTP API for the runtime aspect of this feature.

The building block APIs will be exposed over HTTP; just not the workflow runtime APIs. Indeed, it's a deviation from how other Dapr building blocks work, including actors, but I think it's an appropriate tradeoff that allows us to build a fully-featured workflows runtime implementation. It would be very difficult for someone to correctly implement the workflow runtime APIs using an HTTP client.

Indeed, it's a deviation from how other Dapr building blocks work

Not much of a deviation. The Configuration API started out as gRPC only, and the upcoming Distributed Lock API is also gRPC only.

Sorry I should have said

User code must use this context object from the SDK? There is no option to use a HTTP API or gRPC API

The API surfaces for the building blocks are simple hence why you can bring your own HTTP or GRPC client (and avoid using SDKs) but with the workflow SDK the API surface is complex (as Chris just mentioned) so not using a language specific WF SDK Is unavoidable.
To me it’s fair to say that this is a deviation. Trade-off? Sure, but still a deviation from the status quo. Not trying to be negative btw, just highlighting the gap and how it lightly challenges my perception and expectations of dapr, as a user/consumer.

The API surfaces for the building blocks are simple hence why you can bring your own HTTP or GRPC client (and avoid using SDKs) but with the workflow SDK the API surface is complex (as Chris just mentioned) so not using a language specific WF SDK Is unavoidable.

True, but you'll find it's the same with actors, that de-facto necessitate an Actor SDK to provide a simple programming model that is otherwise very complex when using the APIs directly.

Got it. I forget that dapr Actors require an SDK for the programming model. In that case, ignore everything I’ve said!

@olitomlinson -- I think those are great questions so thanks for asking them! I will avoid sounding like an echo chamber since Chris, Hal and Yaron mostly answered everyone's questions (before I even saw them).
That being said, I can see a world where it might be possible to define workflows without using a language SDK, similar to how GitHub declares its workflows as YAML, with built-in predefined actions (or actions people have written similar to components). However, the explicit goal of this design is to avoid yet another workflow language ("yawful?" :smile:) and allow developers to use their language of choice.

Got it. I forget that dapr Actors require an SDK for the programming model. In that case, ignore everything I’ve said!

No, you did bring up a valid point. While we aim to keep APIs accessible and usable over standard protocols directly (HTTP REST, gRPC) to increase adoption and be inclusive to all programming languages and frameworks, the first principle of Dapr to make developers successful does allow for more opinionated programming models like Actors and Workflows, provided there is a well reasoned, non-nightmarish way to extend them over HTTP and/or gRPC. So far this has worked very well for actors and I've reason to believe based on this proposal that it'll be the same for workflows.

Great proposal it is. I only have one minor question against API, that is, as you said,  there's "A set of APIs for managing workflows (start, schedule, pause, resume, cancel)", but I cannot tell how a workflow can be paused and resumed from the section of "API".

I agree the wording is confusing, but I'm guessing the intent is to use the RaiseEvent API... some external process sends a custom 'PauseEvent' to the workflow, and then later a custom 'ResumeEvent'. The workflow just needs to understand and anticipate those events and react accordingly. Presumably the workflow programming model will expose the events from DaprWorkflowClient or similar (from the code examples above).
Assuming similarity to DTFx (mentioned above as inspiration for this proposal)... application semantics and communication protocol between workflow and outside world are left up to the workflow developer, subject to some constraints imposed by the runtime to provide durability and determinism guarantees.
@cgillum and @johnewart is that the basic idea?

@beiwei30 @jplane sorry for the confusion, this was an oversight. You are correct that pause/resume could be implemented in the workflow logic using external events, and that this is what people have done traditionally with DTFx and Durable Functions. However, our intent for Dapr Workflow is to make this a first class feature that’s built in since it tends to be a pretty useful feature. We’ll update the proposal description to include these APIs.

Just curious, is there any reason that this proposal is not added to the roadmap overview https://github.com/orgs/dapr/projects/52?

Just curious, is there any reason that this proposal is not added to the roadmap overview https://github.com/orgs/dapr/projects/52?

Yes, it hasn't been accepted yet.

Given the parity to Durable Functions programming model, is it in scope to bring across the ContinueAsNew API and the Entities API too? Thanks

is it in scope to bring across the ContinueAsNew API and the Entities API too?

ContinueAsNew, yes - this will be important for application patterns like eternal workflows.
Durable entities is TBD. Dapr already has native support for actors, but I can imagine we might bring it in to support things like distributed critical sections in workflows at some point.

Hi folks, this looks like a great proposal. My name is Mauricio Salatino and I work for the Knative community, I believe that we are evaluating the same topic for Knative and I was wondering if someone interested in workflows in DAPR is going to KubeCon EU in Valencia, Spain, it will be great to catch up and see if we can align some of these initiatives. Feel free to drop me a message here or on Twitter @salaboy

Hi folks, this looks like a great proposal. My name is Mauricio Salatino and I work for the Knative community, I believe that we are evaluating the same topic for Knative and I was wondering if someone interested in workflows in DAPR is going to KubeCon EU in Valencia, Spain, it will be great to catch up and see if we can align some of these initiatives. Feel free to drop me a message here or on Twitter @salaboy

Most Dapr maintainers and STC members won't be attending KubeCon EU physically to the best of my knowledge. It would be best to schedule a virtual call to discuss this.

That sounds good to me. The week after KubeCon might be a good option for me at least, would that work?

That sounds good to me. The week after KubeCon might be a good option for me at least, would that work?

Sounds good. I'll reach out on Twitter after I circle back with the relevant people on the Dapr side.

Amazing to see this proposal! Big yes to it!!

Steering Committee Update
The Dapr STC voted in favor of accepting this proposal and the Workflows building block.

What's the timescales looking like for getting something in hand, even if its just an alpha build that we can play around with? Thanks

What's the timescales looking like for getting something in hand, even if its just an alpha build that we can play around with? Thanks

Since this proposal is accepted by STC, we will start to design and try to bring the first simple, yet runnable demo to quickly verify our ideas and thus it will be a baseline to us for more deep and detail discussion.

For awareness, I've started working on a reference implementation for the embedded workflow engine. If you're interested in following along, it can be found here.
Note that the reference implementation is for demonstrating the feasibility of building a reliable Durable Task-based workflow engine backed by Dapr Actors. It's written in C#, uses the Dapr Actors SDK for .NET, and will run outside the Dapr sidecar. It's not intended to be used in the final implementation. However, it will support the same gRPC contract and can therefore be used to build/test Dapr Workflow SDK implementations in parallel with the actual embedded engine development.

bump so this doesn't go stale

Unfortunately, the stale bot is not aware of people's vacation schedules. 😅
Just as an FYI to interested folks, some initial POC work has been completed and we're hoping to share progress and maybe do some demos at an upcoming Dapr Community Call.

For anyone who may have missed the community call, you can see a recording of the Dapr Workflow POCs using this link: https://www.youtube.com/watch?v=8Aj1WUzVvGs&t=115s.

@cgillum
In this proposal, will Workflows follow the same guidance as Azure Durable Functions regards recommending that any long-running / compute intensive operations are not done in the workflow?

@cgillum
Curious about the retry mechanics. In the demo you show multiple stages as part of the workflow (process order, approve, notify, etc...). If it succeeds in the first operation but fails in the next, will the workflow be tried as a whole again - all steps, including the ones that have succeeded?

@tstojecki
I'm not an authority on this, but theres a couple of ways this could go...

It is up to your user code to try {} catch {} around any Operation that may fail. In the catch {} block perform any necessary compensation around that Operation. An example compensation which might be perform the same operation again aka. a manual retry.

The developer/operator applies custom resiliency policies in Dapr to express the retry mechanism at the CRD/infrastructure.

A combination of both 2 and 3 i.e. Apply resiliency policies first, and then fall back to Exception handling if the resiliency policy is exhausted/unsuccessful.

If Dapr Workflows follows the tried and tested strategy of Azure Durable Functions, then any unhandled/uncaught Exception will put the Workflow into a failed state.
In this failed state you can either :

Restart the workflow from the very beginning, essentially a fresh start. All operations/steps will be executed again regardless of previous attempts.
Restart the workflow from the last known good state, aka rewind to just before the Operation failure, and attempt to try again.

In this proposal, will Workflows follow the same guidance as Azure Durable Functions regards recommending that any long-running / compute intensive operations are not done in the workflow?

Yes, for code-based workflows using the built-in engine, the same basic rules will apply: workflow code should be fully deterministic and should externalize compute intensive processing when possible.

Curious about the retry mechanics. In the demo you show multiple stages as part of the workflow (process order, approve, notify, etc...). If it succeeds in the first operation but fails in the next, will the workflow be tried as a whole again - all steps, including the ones that have succeeded?

Just to add to what @olitomlinson said, there are two types of "failures" to consider:

Application failures - for example, a service invocation returns an HTTP 500 error
Infrastructure failures - for example, a node crashes and brings down your workflow process (or brings down the process of a service you were invoking).

In the first case (application failures), retry policies will be governed by retry policies. Custom resiliency policies will definitely apply and you'll also be able to apply custom logic error handling/retry logic directly in your workflow code using normal error handling constructs, like try/catch (more details on this to come).
In the second case (infrastructure failures), retries will be automatic. For example, if your workflow invokes a service and the node hosting that service crashes, the service invocation will be retried automatically. Similarly, if the node hosting the workflow crashes, the workflow will be restarted automatically and will resume from where it left off. Technically, the workflow will restart its execution from the beginning, but any operations (service invocation, pub/sub, etc.) that were already executed will be skipped and only new operations (the ones that weren't yet started) will be executed.

Technically, the workflow will restart its execution from the beginning, but any operations (service invocation, pub/sub, etc.) that were already executed will be skipped and only new operations (the ones that weren't yet started) will be executed.

Interesting, thanks!
@olitomlinson it sounds like it won't rerun successfully executed operations

Restart the workflow from the very beginning, essentially a fresh start. All operations/steps will be executed again regardless of previous attempts.

Just an update for those who may be interested: the first iteration of the Durable Task Framework clone for Go is here: https://github.com/microsoft/durabletask-go.
This is just the core engine, the gRPC contract (for the runtime), and the core engine abstractions. I verified that it's compatible with the existing gRPC-based Durable Task SDK for .NET (the same one I used as the basis for my POC demo) by running all the existing Durable Task integration tests and pointing them at this engine. This is part 1 of delivering the embedded Dapr Workflow engine.
Part 2 will include the full Dapr integration. The code above doesn't include anything related to Dapr - it's pure Durable Task Framework stuff. In the next phase of the engine work, the plan is to import the above package as a dependency into the Dapr GitHub repo (starting in the feature/workflows branch of dapr/dapr) and implement the Actor-based backend using the Dapr Go SDK. Once this is done, we should be able to faithfully reproduce the previous demo but using the real Dapr sidecar without any POC bits or extra sidecars.

Technically, the workflow will restart its execution from the beginning, but any operations (service invocation, pub/sub, etc.) that were already executed will be skipped and only new operations (the ones that weren't yet started) will be executed.

Interesting, thanks!
@olitomlinson it sounds like it won't rerun successfully executed operations

Restart the workflow from the very beginning, essentially a fresh start. All operations/steps will be executed again regardless of previous attempts.

Sorry, I think we might be confusing two different things here.
I'm going to write here about what Azure Durable Functions does, and then @cgillum can fact-check if this is proposed to be the same for the embedded workflow engine in Dapr, or not.

If there is a transient infrastructure failure/node failure, this will not put the workflow into an terminal status of failed - the workflow runtime will implicitly attempt to bring the workflow back online and resume processing from where the failure occurred.
The alternative transient failure mode is when user-code throws an Exception, which is handled manually by the developer, and/or handled automatically by any resiliency policy. If the exception handling is exhausted, the expectation is that the workflow would transition into a terminal status of failed.
Given a failed state, at this point you as the developer will have the option of restarting the workflow from the beginning (all operations will be re-executed) or rewinding the workflow into its last known good state, and then resuming.

@cgillum As per our brief chat on Twitter, has there been a direction set for the isolation/scoping of registered workflows in a cluster?
Consider the following line where a workflow named ProcessOrder is registered
    options.RegisterWorkflow<OrderPayload, OrderResult>("ProcessOrder", implementation: async (context, input) => { ... }

I would consider the registration to have a scope that follows the convention of :
{namespace}.{dapr_app_id}.ProcessOrder
Such that two Apps with the same dapr App ID on different namespaces residing in the same cluster/dapr environment would not conflict/interfere with each others operation in any way.
Example :
Namespace-A.App-Foo.ProcessOrder
Would not conflict with
Namespace-B.App-Foo.ProcessOrder

This would be inline with recent changes in 1.8 to support isolation of State Management and upcoming changes in 1.9 to support Isolation of Pub Sub

@olitomlinson the workflow engine depends on the state management organization of the underlying actors subsystem. Workflows will therefore inherit the isolation behavior of actors. We’re otherwise not making any explicit decisions about isolation for workflows. If actors are improved with better isolation guarantees, then workflows should be able to easily inherit the same improvements.

@cgillum An Actor is essentially isolated by its Actor ID. Is there any reason that the namespace and app Id can't be included in the Actor ID to get that isolation?

That's certainly an option, though I think it would be cleaner if the actor subsystem could take care of namespace prefixing for us.

It definitely would be cleaner, you're right there.
I only raise this because we can't use Dapr Actors directly in our product due to the inability to have namespace isolation of Actors. I would hate that Dapr Workflows falls into the same trapping, and once again, my team are unable to access another really valuable programming model.

JFYI, first PR into the feature/workflows branch has been merged: https://github.com/dapr/dapr/pull/5301.
It introduces an internal actor concept which is used by the new durable task-based workflow engine. More PRs will be published over the next few weeks that flesh out the full workflow engine feature set.

This is awesome, looking forward to testing this.  We have just started to deploy and test 60+ microservices that were code-generated by our DDD based Domain Modeling tooling and all running with DAPR inside Azure Container Apps.   These services are for ERP capabilities, core services and future product offerings.
We plan to utilize your DAPR WF to manage any long running WF and SAGAs.
In the not too distant future we are planning to build our own WF Editor based upon the Serverless WFhttps://www.cncf.io/projects/serverless-workflow/ specification as per CNCF which will allow us to create both Code-based and Declarative-based WF.  Just can’t wait!
Best Wishes,
John Kears
NOTICE TO RECIPIENT: This communication with its contents is meant only for the intended recipient of the transmission, and may contain confidential information and/or legally privileged information.  Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act.  If you are not the intended recipient, please contact the sender and destroy all copies of the communication.  Thank you in advance for your cooperation.
From: Chris @.>
Sent: October 7, 2022 8:20 PM
To: @.>
Cc: John @.>; @.>
Subject: Re: [dapr/dapr] [Proposal] Workflow building block and engine (Issue #4576)
JFYI, first PR into the feature/workflows branch has been merged: #5301https://github.com/dapr/dapr/pull/5301.
It introduces an internal actor concept which is used by the new durable task-based workflow engine. More PRs will be published over the next few weeks that flesh out the full workflow engine feature set.
—
Reply to this email directly, view it on GitHubhttps://github.com/dapr/dapr/issues/4576#issuecomment-1272174643, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJ3FONHLJ3CKIMAZE46N3LWCC45DANCNFSM5U5LNZBQ.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Linking dotnet-sdk proposal for dapr workflows:
https://github.com/dapr/dapr/issues/5314

Frieds, If you're interested in the Serverless Workflow specification for this effort, please let us know! We are at the CNCF slack, #serverless-workflow channel.

@msfussell
FYI that the search term "dapr workflows" in google is probably returning less favourable results for when 1.10 ships - I suspect it would be desirable to be returning the new Workflow building block documentation, rather than the sandbox project?


Feature Update: Displaying Top 5 Classification Results per Seed in Nachet Frontend

Summary
Enhance the Nachet Frontend to display the top 5 classification results for each seed, based on the new topResult attribute being passed from the Nachet Backend. This feature aims to allow users to view alternative classifications for each detected seed, aiding in identifying misclassifications and improving AI model training.
Background
The current classification functionality in Nachet Frontend visualizes seeds within images using rectangle boxes, with the backend providing details such as the box dimensions, top label prediction, confidence score, and overlap information. The introduction of a topResult attribute by the backend will now include the top 5 classification results for each seed.
Proposed Functionality
To effectively leverage the topResult data, we propose introducing an interactive component that displays the top 5 classification results for a selected seed. Two design approaches are under consideration:

Seed Selection Pop-up: Clicking on a specific seed box triggers a pop-up to display the top 5 classification results.
Results Table Interaction: Clicking on an entry in the seed classification results table opens a pop-up with the top 5 results for the selected seed.

Both methods aim to provide detailed insight into the classification process, offering users the ability to flag misclassifications directly. For more details on the design aspect, refer to the discussion with Maxence here.
Changes to Configuration

With the introduction of topResult, the threshold slider in the results tuner configuration will be removed as it will no longer be utilized.

Possible Extension
Consider the feasibility of allowing users to directly escalate issues from the classification pop-up, possibly automating the creation of a GitHub issue for further investigation.
Implementation Considerations

UI/UX Design: The design of the pop-up component should be intuitive and seamlessly integrate with the current interface. It should clearly present the top 5 results, along with their confidence scores and labels.
Interaction Design: Decide on the interaction flow for accessing the top results—whether through direct seed selection or via the results table—and ensure a consistent and user-friendly experience.
Error Handling: Implement robust error handling to manage cases where topResult data might be incomplete or missing.
Backend Integration: Ensure that the frontend correctly handles the updated response structure, including the new topResult attribute.

Test Cases Checklist

[ ] Verify that the top 5 classification results are accurately displayed for seeds upon interaction.
[ ] Ensure that the pop-up component functions correctly across different devices and screen sizes.
[ ] Test the user flow for flagging misclassifications directly from the pop-up component.

The plural is good, I also like candidates. From what I understand from the discussion with Amir and Noureddine, a model could eventually send back n results and not just 1 or 5. So I would avoid top5 to keep flexibility for the property.
We can also use topN as described in this article comparing top1 vs topN accuracy score:
https://medium.com/nanonets/evaluating-models-using-the-top-n-accuracy-metrics-c0355b36f91b

topN seems good.
"Top N accuracy — Top N accuracy is when you measure how often your predicted class falls in the top N values of your softmax distribution."


Carthage Support

Any chance you could add support for Carthage? Currently when trying to pull, one is confronted with the following message:
No tagged versions found for github "hackiftekhar/IQMediaPickerController"
Which implies it might be as easy as adding some sort of tag. I am not certain of the requirement to support Carthage but that initial message seems as though adding support might be trivial. I'd prefer Carthage because the overhead with cocoa pods  is something I'd like to avoid and I am used to adding additional frameworks to the IDE (as others may be as well).
Found on SO that one can simply add the branch to the Cartfile. (http://stackoverflow.com/questions/31069315/carthage-errors-no-tagged-versions-found-for-github)
Cartfile
github "hackiftekhar/IQMediaPickerController" "master"
However this led to an error:
Dependency "IQMediaPickerController" has no shared framework schemes
Turns out that SO had this to say
Basically the shared scheme is not being added to the git repo.
(http://stackoverflow.com/questions/35054788/carthage-no-shared-framework-schemes-for-ios-platform-for-my-own-framework)
Framework Support
Medium actually has a nice article on making a Carthage framework<EMAIL_ADDRESS>Shared Framework Scheme
Found an option to share Scheme on the Edit Scheme dialog box (Product > Edit Scheme)

I'll try to work on this and will create a framework target for Carthage support.


Added Multilevel Push Navigation Bar

Fixes Issue🛠

Closes #935
Description👨💻
I've added multilevel push navigation bar, which is a sidebar menu that has 3 different demos in it. The first one is overlapping levels, second is the covering levels and the third is the overlapping levels with back links.
Type of Change📄

[x] New feature (non-breaking change which adds functionality)

Checklist✅

[x] I am an Open Source contributor
[x] I have performed a self-review of my code
[x] My code follows the style guidelines of this project
[x] I have commented on my code, particularly in hard-to-understand areas

Screenshots/GIF📷

https://github.com/Rakesh9100/Beautiify/assets/129776752/71b3e6bb-c945-470d-a891-e844904729a8

Can I know why have you closed your previous PR and also why this component has these many files, it seems like you have just copied the code and pasting here @itssarvani394


Test API updates

Description of the change

Updated Test API documentation to include information on overriding destination configuration via the testDestination endpoint.

Type of change

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Related issues

Fix #1

Checklists
Development

[ ] Lint rules pass locally
[ ] The code changed/added as part of this pull request has been covered with tests
[ ] All tests related to the changed code pass in development

Code review

[ ]  This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
[ ] "Ready for review" label attached to the PR and reviewers mentioned in a comment
[ ] Changes have been reviewed by at least one other engineer
[ ] Issue from task tracker has a link to this pull request

LGTM


python38Packages.pandas: fix build on darwin

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/93875
cc @nbren12
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Thanks @marsam for the quick fix!


Fix NPE around unschedulable pod specs

Fixes #77
This is another instance where our minikube ete tests aren't sufficient to catch problems running on live clusters, like the kubeadm-created one I've been testing with.

@foxish we have to check nullability here (good practice anyway) because apparently my kubeadm-created cluster doesn't set Unschedulable on some/all of the nodes.
@mccheah good to merge this hotfix when this build is green?

That makes sense, and is true of other clusters as well. The absence of unschedulable is equivalent to it being marked false.

LGTM

Looks fine.


Update to Cadence v0.24.1

For contributor use:

[x] Targeted PR against master branch
[x] Linked to GitHub issue with discussion and accepted design OR link to spec that describes this work
[x] Code follows the standards mentioned here
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the GitHub PR explorer
[x] Added appropriate labels

Codecov Report

Merging #158 (a06671d) into master (8b158a3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #158   +/-   ##
=======================================
  Coverage   52.91%   52.91%
=======================================
  Files          20       20
  Lines        1958     1958
=======================================
  Hits         1036     1036
  Misses        808      808
  Partials      114      114

Flag
Coverage Δ

unittests
52.91% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b158a3...a06671d. Read the comment docs.


LineChart disable inner dash lines not working

I want to disable the inner dash lines and so I set  withInnerLines="false" but still the lines are visible .How do I achieve a blank background to the line chart ?

solved it by  withInnerLines={false}


Bug Fix: CI pipeline

Updated postman collection and environment files
Modified list and search APIs to use open and secure tokens as per the resource openness <open resource/resource groups shall use an open token and secure resource/resource groups will expect secure tokens>

Can one of the admins verify this patch?


Fixing empty body not populating Exception message

Today I was trying to test out some code but my Bandwidth Test creds were incorrect. The ClientException was thrown, but because the Iris\ResponseException populates the message with the $body rather than the message from the exception, $exception->getMessage() returned nothing helpful.
This modifies parseExceptionResponse() to:

explicitly set $body to a string rather than having the object convert on the fly
If $body doesn't contain anything in the response or error sections, simply pass the Exception message that raised it in the first place to pass it through to the client

Tests are written, they fail before the change and pass after.

@jmulford-bandwidth @bwdan I'd love to get this committed!

Hey @ooglek thanks for submitting this! We are going through some internal changes and part of that includes a new format for open source submissions to our SDKs. We will get back to you when that is finalized.
Thank you,
Jacob

Thanks for your contribution!


Make all update operations atomic

Currently some of the rquests are issuing multiple INSERT/Update requests to DB. We need to make all such occurrences atomic by enclosing them in transaction boundaries.
For example : See https://github.com/LSFLK/MedicinesforLK-AdminAPI/blob/main/db_processor.bal#L307:L308
We need to make sure both operations are either successful or none.
Check all the places for similar issues.

@anupama-pathirage can you take this on? can you recommend someone?

@anupama-pathirage can you take this on? can you recommend someone?

I will look on to this

@anupama-pathirage can you take this on? can you recommend someone?

I will look on to this

https://github.com/LSFLK/MedicinesforLK-AdminAPI/pull/80/files


Automation of 3 APIs of ClusterRouter

Summary
Here I am trying to reduce time for functional testing via Automating the APIs
Motivation
We will run this automation every time before releasing our build on any enterprises account or OSS
Proposal
In this module I'll cover below 2 new APIs of ClusterRouter
POST       /orchestrator/cluster ==>SaveCluster
GET         /orchestrator/cluster?id={id} ==>GetClusterById
DELETE   /orchestrator/cluster ==> DeleteCluster

All three APIs of this card are automated so closing it.


Docs: missing information about empty/anonymous interfaces

Hi, I noticed the following commit in facebook/relay repo: codemod objects to interfaces where they appear as supertypes of classes. There are many changes but one which stood up for me was this one:
- export type Variables = {+[string]: $FlowFixMe, ...};
+ export type Variables = interface {+[string]: $FlowFixMe};

The reason it caught my attention is because it started causing some Flow errors in our code and I do not understand the behavior very much. Before:
type Variables = {+[string]: any, ...};
const x: Variables = null; // Error (null is incompatible with Variables)

After:
type Variables = interface {+[string]: any}

const x: Variables = null; // No errors!
const y: Variables = -1; // No errors!
const z: Variables = "ups"; // No errors!

So this change made the code less sound. 🤔
How does this empty/anonymous interface (I don't know how to call it better) work? Is it the same as interface with indexer properties described in the docs (https://flow.org/en/docs/types/interfaces/)? So in other words the same like writing this?
interface Variables {
  +[string]: any;
}

const x: Variables = null; // No errors!
const y: Variables = -1; // No errors!
const z: Variables = "ups"; // No errors!

Why it accepts anything and behaves almost like any type? What is the motivation behind this change? cc @dsainati1
Thank you very much for some insights and for helping me understand it better! 😎

This particular change to Variables is actually being rolled back.
However, in general anonymous interfaces behave identically to named interfaces like in the example you linked. As for why it accepts "anything", it does not in fact accept anything. The issue with the loose typing around Variables is because it is written to be an indexer whose value is any, which is very unsafe. More strictly typed interfaces will give you better guarantees about your code. In general, an interface describes the accessible properties on a structure (not just an object). So interface { length : number} is a supertype of { length : number} and also string.
Your example with null is a bug however, so I should fix that. Thanks for the heads up.


FSEV stopped every time Mac OS High Sierra sleeps

This appears to be a similar issue to #262, however the current behavior is on 4.6.4 on High Sierra and with a slightly different error log, please see below.
On Mac OS High Sierra, using Dinghy version 4.6.4, nearly every time that my laptop wakes from sleep, I see the following:

Dinghy status
$ dinghy status
   VM: running
  NFS: running
 FSEV: stopped
  DNS: running
PROXY: running

FsEvents failed to run
details available in log file: /usr/local/Cellar/dinghy/4.6.4/local/var/dinghy-FsEvents.output

Your environment variables are already set correctly.

FsEvents Error Log
$ cat /usr/local/Cellar/dinghy/4.6.4/local/var/dinghy-FsEvents.output

=== Starting FsEvents at 2018-06-20T11:05:35-04:00 ===

`rror running command `gtouch -m -c -d 2018-06-20T22:39:10.137628790Z /Users/username/Dropbox/Icon\
Errno::EHOSTUNREACH: No route to host - recvfrom(2)
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/buffered_io.rb:65:in `recv'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/buffered_io.rb:65:in `fill'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:272:in `block in ev_do_handle_events'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:268:in `each'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:268:in `ev_do_handle_events'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/event_loop.rb:110:in `ev_select_and_postprocess'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/event_loop.rb:29:in `process'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:225:in `process'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:178:in `block in loop'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:178:in `loop'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:178:in `loop'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/channel.rb:269:in `wait'
	/usr/local/Cellar/dinghy/4.6.4/cli/net-ssh/lib/net/ssh/connection/session.rb:425:in `exec!'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/ssh_exec.rb:15:in `exec!'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/ssh_emit.rb:12:in `emit!'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/cli.rb:34:in `block in start'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/watch.rb:14:in `block (2 levels) in run'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/watch.rb:12:in `each'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/watch.rb:12:in `block in run'
	/usr/local/Cellar/dinghy/4.6.4/cli/rb-fsevent/lib/rb-fsevent/fsevent.rb:77:in `run'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/watch.rb:17:in `run'
	/usr/local/Cellar/dinghy/4.6.4/cli/fsevents_to_vm/lib/fsevents_to_vm/cli.rb:28:in `start'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/command.rb:27:in `run'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/invocation.rb:126:in `invoke_command'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor.rb:359:in `dispatch'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/base.rb:440:in `start'
	/usr/local/Cellar/dinghy/4.6.4/cli/dinghy/fsevents_to_vm.rb:39:in `run'
	/usr/local/Cellar/dinghy/4.6.4/cli/daemons/lib/daemons/application.rb:270:in `call'
	/usr/local/Cellar/dinghy/4.6.4/cli/daemons/lib/daemons/application.rb:270:in `block in start_proc'
	/usr/local/Cellar/dinghy/4.6.4/cli/daemons/lib/daemons/daemonize.rb:84:in `call_as_daemon'
	/usr/local/Cellar/dinghy/4.6.4/cli/daemons/lib/daemons/application.rb:274:in `start_proc'
	/usr/local/Cellar/dinghy/4.6.4/cli/daemons/lib/daemons/application.rb:300:in `start'
	/usr/local/Cellar/dinghy/4.6.4/cli/dinghy/daemon.rb:73:in `start'
	/usr/local/Cellar/dinghy/4.6.4/cli/dinghy/daemon.rb:14:in `up'
	/usr/local/Cellar/dinghy/4.6.4/cli/dinghy/fsevents_to_vm.rb:14:in `up'
	/usr/local/Cellar/dinghy/4.6.4/cli/cli.rb:283:in `start_services'
	/usr/local/Cellar/dinghy/4.6.4/cli/cli.rb:93:in `up'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/command.rb:27:in `run'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/invocation.rb:126:in `invoke_command'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor.rb:359:in `dispatch'
	/usr/local/Cellar/dinghy/4.6.4/cli/thor/lib/thor/base.rb:440:in `start'
	/usr/local/bin/_dinghy_command:12:in `<main>'

Things I notice here, in no particular order:

Somewhere we are logging "rror" instead of "Error"
As the system wakes up, the SSH connection probably needs to be re-established in the case of these sorts of failures, right?

That "rror" logging is just because of the weird filename that MacOS uses for its hidden icon files -- it is "Icon\r", so while printing it out we carriage return and overwrite the first part of the line again. We could print the command as a string literal #{command.inspect} to fix.
I'm not sure why this is killing fsevents_to_vm completely though, since it is catching the error and calling SShExec#disconnect! as we'd expect. I'd expect to at least see more error logging, if that subsequent SSH reconnect fails. I'll have to see if I can repro and debug.

I was able to repro a very similar error by simply stopping dinghy while running an independent fsevents_to_vm process. The hard failure is in the @ssh.close line which fails when the SSH connection has already failed, so I've added error handling to that.
It appears the reason that second error wasn't getting logged is because the rb-fsevents library we're using to monitor FS events is swallowing that type of error and silently failing, which is disturbing. I'll see if I can do anything about that.
But this particular failure should be fixed by https://github.com/codekitchen/fsevents_to_vm/commit/9a32dbcc2589cea0cbc105b237290b54e17b215a which will be included with the next Dinghy release.

Thanks once again @codekitchen !

Yeah, I've been waiting for another PR to be completed but I'm not sure where it's at so I just published version 4.6.5.


Create schema.org publication transform

Given a VIVO Publication object (https://wiki.lyrasis.org/display/VIVODOC110x/Publication+Model), the transform should spit out a schema.org ScholarlyArticle object (https://schema.org/ScholarlyArticle).  This should be isomorphic, ie run in both Node and browser JS lands.

This may need to support vivo:ConferencePaper as well.  @qjhart  ?

Yes, for potential differentiation.  We should include the vivo type for all publications as well, even though they won't necessarily be used in any schema.org specific context, it wouldn't hurt to show.

I don't think indicating the title as a "headline" is necessarily wrong given that it's a property inherited from CreativeWork--of which ScholarlyArticle is a subtype--but it seems less applicable here that it would be to, say, a news article.

Looking at Bryan Jenkins, I see jobTitle represented as
"jobTitle": [
    "AGRON AES-B/E/E",
    "PROF-FY-B/E/E",
    "DEPARTMENT CHAIR",
    "Chair and Professor"
  ],

In the Schema.org example, there's this example:
"jobTitle": {
        "@type": "DefinedTerm",
        "inDefinedTermSet": "https://targetjobs.co.uk/careers-advice/job-descriptions",
        "termCode": "277133-aid-workerhumanitarian-worker-job-description",
        "name": "Aid worker/humanitarian worker",
        "url": "https://targetjobs.co.uk/careers-advice/job-descriptions/277133-aid-workerhumanitarian-worker-job-description"
    }

Perhaps our jobTitle should be changed to an array of name objects, e.g.,
 "jobTitle": [
    {
      "@type": "Text",
      "name": "AGRON AES-B/E/E"
    },
    {
      "@type": "Text",
      "name": "PROF-FY-B/E/E""
    },
    {
      "@type": "Text",
      "name": "DEPARTMENT CHAIR""
    },
    {
      "@type": "Text",
      "name": "Chair and Professor"
    }
  ]

Re: "knowsAbout," the application of DefinedTerms to people appears to be an AE (JM) innovation, as  this page doesn't appear to depict that but rather limits terms to describing a work's aboutness.


Update client test to mach go 1.5 http errors

Go 1.5 will return a different error message for http timeout.
Ref: https://github.com/golang/go/issues/9405

Thanks!

@jenspinney  && @krishicks


changeSet

pull req

Hey rikardo409@, looks like you are trying to merge in your own changes to the demo guide. Did you mean to check those in to your own repo?


Extract buildSetting manipulation into two methods

This is needed for the consolidated targets work.

Best viewed with whitespace changes hidden: https://github.com/buildbuddy-io/rules_xcodeproj/pull/465/files?diff=unified&w=1


Package request: BiglyBT

Project description
A feature filled, open source, ad-free, bittorrent client. It is forked from the original project and is being maintained by two of the original developers as well as members of the community. With over 15 years of development, there's a good chance we have the features you are looking for, as well as the decade old bugs you aren't looking for.
Metadata

homepage URL: https://github.com/BiglySoftware/BiglyBT
source URL: https://github.com/BiglySoftware/BiglyBT
license: gpl2
platforms: unix, linux, darwin

#213735


Swiggy Clone website

Description of  the change
I want to work on this project ,kindly assign me this
Domain of Docs

[] Readme
[] Solidity , Html, Css , JavaScript , Web3.js / Ether.js
[] Solidity , ReactJs /NextJs , Web3.js /Ether.js
[] Solidity , Python3 , Web3.py
[] Other , feel free to mention below

Are you contributing under any open-source program ?
Yes, in SSOC

@TanyaNegi10 assigned to you. Start working on this project.

@TanyaNegi10 closing this issue, as this project is already present in this repo. Please come up with some new ideas!


CapsLock sending multiple keyDown without autorepeat flag

Sometimes, on a single key stroke, 2 keyDown events are sent, and then 2 keyUp event are sent.
The problem is that the second keyDown event doesn't have the autorepeat flag like it should, causing 2 characters to be introduced, instead of triggering the "character accent selector". It also disrupts other tools which rely on the keyboard-repeat events.
This occurs only when remapping CapsLock to other key.
It only happens some times, depending on timing.
It might happen when the key release matches the moment the key-repeat should start, but I'm not sure about this.
Example:
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: true | type: keyDown # this is ok
key: capsLock | autorepeat: true | type: keyDown # this is ok
key: capsLock | autorepeat: true | type: keyDown # this is ok
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyDown # this should never happen
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyUp # this should never happen
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyUp
key: capsLock | autorepeat: false | type: keyDown
key: capsLock | autorepeat: false | type: keyUp

Karabiner-Elements 0.90.92 (think this didn't happen before this version)
macOs 10.124

This doesn't seem to happen with a MacBook Air 2011, but happens with a MacBook Pro 2016.

I experienced the same issue and managed to solve it by adding repeat: false to the to event definition
like so :
"simple_modifications": [
 	{
        "from": {
            "key_code": "caps_lock",
        },
        "to": {
            "key_code": "escape",
            "repeat": false
        }
    },
]


Add i18n and add translation strings to the command package

Summary
This would be the first step for the localisation of the plugin.
It follows the same pattern as the Jitsi plugin.
Only the command package and some minor strings in other places are in the translations. We should create tickets to convert all user facing strings to i18n, package by package.
This has nothing to do with App localization. Future work will be done on that front.
Documentation on how to contribute in the translations should be added.
Ticket Link
None

Codecov Report

Merging #218 (a57ede3) into master (6957ee6) will decrease coverage by 0.46%.
The diff coverage is 2.29%.

@@            Coverage Diff             @@
##           master     #218      +/-   ##
==========================================
- Coverage   21.97%   21.50%   -0.47%
==========================================
  Files          52       52
  Lines        3049     3120      +71
==========================================
+ Hits          670      671       +1
- Misses       2322     2392      +70
  Partials       57       57

Impacted Files
Coverage Δ

server/httpin/restapi/app.go
0.00% <0.00%> (ø)

server/proxy/service.go
0.00% <0.00%> (ø)

server/proxy/uninstall.go
0.00% <0.00%> (ø)

utils/utils.go
0.00% <0.00%> (ø)

server/httpin/restapi/restapi.go
88.63% <100.00%> (+0.26%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6957ee6...a57ede3. Read the comment docs.

@larkox Do we need a ticket for documentation for contributing to translations as noted in the description? Also will this be integrated with the translation servers?

Great work here @larkox :+1: Looking forward to seeing more languages getting added.

@hanzei @catalintomai Improved a bit on this after our last talk. This is how it looks now for commands:

I added another minor change that is removing the error return. It was not being used, and was prone to future mistakes thinking it will be used. Now it is more clear that you must return a command response, whether it is an error or not.

@larkox Heads up that I merged master into your PR. Hope you are fine with that.

Blocking this PR since https://github.com/mattermost/mattermost-plugin-apps/pull/251 will remove the whole command package. We may use this to dogfood our own localization system for apps.

@larkox Oops... we need to seriously rebase this

/check-cla

@hanzei Regarding the install modal, I can take a look. My objective was to keep things to the commands, but seems a quick win localizing that too.
Regarding errors, that would mean go down to other packages, and get back to the discussion on whether we should show the english error, the localized error, both, or what. That discussion was more or less sorted on the previous version of this ticket, but I could foresee that discussion being reopened. Because of that, I prefer to keep it so far like this, and keep on translating on the next iteration (maybe with help of the community?).


[BUG] Flight spell works indefinitely

I haven't tested this much but on my friends fabric server when casting the flight spell I can cast it with values of 0 consuming 0 media and still be able to fly without any limits.

I've also experienced this recently on fabric.

Specific cause :
OpFlight.INSTANCE.tickDownFlight(evt.getEntityLiving()); is only registered as an event for Forge.  The closest comparable call in FabricHexInitializer.kt is ServerTickEvents.END_WORLD_TICK.register(PlayerPositionRecorder::updateAllPlayers), which does not eventually touch OpFlight.INSTANCE.tickDownFlight and seems to mostly be focused on adjusting for MC's various player position jankiness.
Adding OpFlight.INSTANCE.tickDownFlight(player); into the main player loop at void updateAllPlayers(ServerLevel world) fixes the problem but kinda violates the Do One Thing Right rule; alternatively, adding into OpFlight and then registering as an EndWorldTick
   {
       for (player in world.players()) {
           tickDownFlight(player)
       }
   }```

Seems to be valid and more 'correct', albeit at the cost of less clear division between Fabric and Forge code.


Configurator dead

Home Assistant release with the issue:

**Last working Home Assistant release (if known):80.2
**Operating environment (Hass.io/Docker/Windows/etc.):hassio

**Component/platform:Pi3

**Description of problem:configurator not showing
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

We're going to need more information. What component(s) are you trying to configure? Any errors in the logs?

Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? Thanks!

Closing due to lack of information and no response after 6 months.


Issue with identity columns should be listed?

I see the below issue when I try to run the migration, I dont see this listed anywhere here? is this a know issue?
"Failed to execute statement: 'SET IDENTITY_INSERT [dbo].[MonitoringType] ON'",
"RetCode: SQL_ERROR  SqlState: 42000 NativeError: 8107 Message: [Microsoft][SQL Server Native Client 11.0][SQL Server]IDENTITY_INSERT is already ON for table '823047(Online-mig).dbo.D_ScanFiles'. Cannot perform SET operation for table 'dbo.MonitoringType'. Line: 1 Column: -1",
"Failed to set IDENTITY_INSERT on table dbo.MonitoringType",
"Error executing data handler",
"Stream component failed at subtask 9, component st_9_79c298f8-8ca7-4db3-8af0-8a3d46c462fb ",
"Stream component 'st_9_79c298f8-8ca7-4db3-8af0-8a3d46c462fb' terminated",
"Task error notification received from subtask 9, thread 1",
"Task '13e17789-6a24-416a-b734-29a3b3eb7904' encountered a fatal error"
]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1d8742b3-4494-c8a1-29bb-17e805d07fea
Version Independent ID: 891dff61-83dc-d21a-b0e3-ed89b9949516
Content: Article about known issues/migration limitations with online migrations to Azure SQL Database
Content Source: articles/dms/known-issues-azure-sql-online.md
Service: database-migration
GitHub Login: @pochiraju
Microsoft Alias: rajpo

@Anmolgan81 Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

#reassign:HJToland3

@Anmolgan81, I am checking with the support team on this one, though it appears that they've not seen this issue reported recently.  Are you still encountering the problem?  Thanks!

@HJToland3
I think DMS product group fixed this, I haven't check this for a long time so am not sure if thats fixed or still in the works? Can you confirm if this is completed?

@Anmolgan81, yes, this issue has been resolved and a fix has been deployed to all production regions.

@HJToland3 Thanks for confirming the issue is resolved. @Anmolgan81 We are going ahead and closing this issue. If you have any concerns, please get back to us and we will try to provide necessary help regarding the same.


Fix for k8gb.io mixed content warnings

Fixing mixed content warnings on visiting k8gb.io website:
Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/MluFlwPFZws/hqdefault.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):2 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/5pe3ezSnVI8/hqdefault.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):2 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/5DhO9C2NCrk/0.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):2 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/jeUeRQM-ZyM/0.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):1 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/MluFlwPFZws/hqdefault.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):1 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/5pe3ezSnVI8/hqdefault.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):1 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/5DhO9C2NCrk/0.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
(index):1 Mixed Content: The page at 'https://www.k8gb.io/' was loaded over HTTPS, but requested an insecure element 'http://img.youtube.com/vi/jeUeRQM-ZyM/0.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content
Signed-off-by: Timofey Ilinykh<EMAIL_ADDRESS>

Watching github preview and would be nice to align,
Consider central alignment:
| Tables   |      Are      |  Cool |
|----------|:-------------:|------:|
| col 1 is |  left-aligned | $1600 |
| col 2 is |    centered   |   $12 |
| col 3 is | right-aligned |    $1 |

@kuritka amended, also using a compact format from www.tablesgenerator.com/markdown_tables to make markdown looking simpler in editor.


Link to CpeManager broken on Baleen Landing page

In the quick start information on the Baleen landing page, the link to CpeManager is broken as it's been renamed in 2.2.0 to PipelineCpeBuilder.

This has been addressed and will be fixed in a future release.

Fixed in 2.3.0-SNAPSHOT


Fixed events variable error.

does it fixed #3 ?

Installed your branch in my Gemfile:
gem 'rails_admin_aasm', :git => 'https://github.com/troyanryller/rails_admin_aasm/', :branch => 'feature/fix-undefined-events-variable'
still get this same issue. Any help?

It should be fixed after adding attr_accessor :my-state-field-name_event to your model. Also mention about it in readme.md

:-( Can't understand how to get this work. What should state_event method return?

@rstormsf nothing, it should be only like temporary variable for model, so in model:
attr_accessor :state_event

should fix your problem. If u have other name for aasm field then u need to specify different accessor, for example i got status field for aasm statuses, so i add attr_accessor :status_event to my model and
    rails_admin do
      list do
        field :account
        field :status, :state
        ....

Hi @troyanryller  thanks for contribution, I think this pr is duplicated with https://github.com/zcpdog/rails_admin_aasm/pull/1  what do you think

@zcpdod yep, main fix is same...


Receiving a "No Activity found to handle Intent' exception on Android

@EddyVerbruggen
Currently on:
Cordova Android: 7.1.4
Android Target SDK: API 27
Android Compiled SDK: API 27
I'm attempting to open the url "www.google.com" using this library and experiencing an exception.
Error:  "No Activity found to handle Intent { act=android.intent.action.VIEW dat=www.google.com pkg=com.android.chrome launchParam=MultiScreenLaunchParams { mDisplayId=0 mFlags=0 } (has extras) }"
After debugging the ChromeCustomTabPlugin.java class I was able to drill down and see the issue is occurring within the call on line 186 of this class. Specifically inside this method, the exception is thrown upon hitting the CordovaActivity.java class when calling super.startActivityForResult after the supplied activity calls startActivityForResult and passes the intent and request code.
It appears the activity is not null at any point during this process as the debugger shows the activity passed is the MainActivity.
I've confirmed the chrome package is installed and the app recognizes this package.
I'm wondering if this is a versioning issue or I haven't installed the library correctly. Any insight would be great.

Also getting a similar error, just different pkg, since I'm using chrome beta as my default browser


is the project abandoned?

hope not

project's atm on hold as I can't come up with any other / better method to avoid memory issues.
Aside, considering onnx exported models have to some degree worse quality+ isn't that much faster than rvc in cpu mode, there's currently no reason to rely on onnx.


Fix file access in docker container

This PR fixes issues with writing/reading Swagger Accounts and Payments file permissions in a docker container.
Specifically:

Remove unnecessary DIR permissions in the Dockerfile.

@mbana that was lightning quick.


I get this error when calculating a 15MW floating turbine

When calculating the case of a 15MW floating turbine, I had already completed the calculation of the rated wind speed, but after many cases, this error appeared when I changed the turbulence to make a new calculation, and then I tried to go back to the beginning of the calculation of the rated wind speed case, and I found that I could not solve the error, and the only way to do the calculation is to turn off the servo and inflowl modules at the same time, but I didn't find the settings in these two modules that are unreasonable, so how to solve it, please?
"Running InflowWind.
FAST_InitializeAll:ED_Init:ED_ReadInput:ReadPrimaryFile:Number of tower strain gages exceeds 9.
FAST_InitializeAll:AD_Init:Init_BEMTmodule:BEMT_Init:UA_Init:UA_SetParameters:UA_ValidateAFI:UA
cutout parameter should be at a value where the separation function is 0 in
".../IEA-15-240-RWT/Airfoils/IEA-15-240-RWT_AeroDyn15_Polar_01.dat". Separation function is
3.93793E-02
UA_SetParameters:UA_ValidateAFI:The separation function f_st does not reach 1 in
".../IEA-15-240-RWT/Airfoils/IEA-15-240-RWT_AeroDyn15_Polar_02.dat". max(f_st)=0.47372. Check
the calculation or provide f_st in the input file.
UA_SetParameters:UA_ValidateAFI:Large difference between C_lalpha and C_nalpha in
".../IEA-15-240-RWT/Airfoils/IEA-15-240-RWT_AeroDyn15_Polar_03.dat". C_lalpha=3.2819 C_nalpha=0.
We advise to check these value or provide them in the input file.
UA_SetParameters:UA_ValidateAFI:Large difference between C_lalpha and C_nalpha in
".../IEA-15-240-RWT/Airfoils/IEA-15-240-RWT_AeroDyn15_Polar_04.dat". C_lalpha=5.5538 C_nalpha=0
OpenFAST encountered an error during module initialization.
Simulation error level: FATAL ERROR
Aborting OpenFAST."
Best regards

Yes, I was checking and realised that UAMOD was set to 6, I have absolutely no recollection of when I changed this option, the correction has resolved the issue, thank you for your help!
Best regards,


Refactoring for release

Current coverage is 96.93%

Merging #24 into master will decrease coverage by -1.37% as of 167ce44

@@            master     #24   diff @@
======================================
  Files           32      32
  Stmts          708     782    +74
  Branches         0       0
  Methods
======================================
+ Hit            696     758    +62
  Partial          0       0
- Missed          12      24    +12

Review entire Coverage Diff as of 167ce44

Uncovered Suggestions

+0.51% via .../MarkdownFactory.php#95...98
+0.38% via src/Markdown.php#56...58
+0.25% via ...ckParagraphStart.php#22...23
See 7 more...

Powered by Codecov. Updated on successful CI builds.


Crash on Server start

Version 0.2.1 of DR, 1.3.0 of mcjtylib, 1.4.130 of eleccore
crash: http://pastebin.com/W85r0nJ5

Hopefully fixed next version which is waiting for approval