danielduarte / flowed Goto Github PK

Optional results post-processing to make possible some simple processing without adding more tasks.
Examples of processing:

• Extract a field from an object
• Create an object from a value
• Create a string from a value
• Convert an object into another one

Maybe I don't understand this moment from docs, but can change next task from current?

For example, taskA ended and now result = 1, and now flow go to TaskB, at next time on end TaskA result = 2 and now flow go to TaskC. How I can realize this flow with flowed?

Make optional params and results mapping when names and aliases are the same.

When a resolver does not have a return statement, the following error appears in console, misleading on the proper way to solve the issue:

(node:56642) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'hasOwnProperty' of undefined
    at Task.mapResultsFromResolver (/.../node_modules/flowed/dist/engine/task.js:113:31)
    at /.../node_modules/flowed/dist/engine/task.js:57:38

Add transaction support to group tasks into an atomic, undoable transaction.

Is your feature request related to a problem? Please describe.
I need to cal useQuery apollo hook and with resolvers as class components I am not able to do so.

Describe the solution you'd like
Library should accept resolver as simple functions also.

Describe alternatives you've considered
I tried to write resolver as a functional component but then it failed with error like "this.taskResolverConstructor is not a constructor".

Add an option/way to indicate for a task that all its provided values are mandatory.
Fail if any of them is missing.

From the examples I have looked over and the testing I have run, it does not appear that trueResult/FalseResult parameters can be set to a hardcoded line of text, but have to be fed their values from an entry in the parameter object.

If you have a flow spec with multiple conditionals which each have different true/false results, it would be easier to be able to write those directly in the params instead of having to feed in multiple different key/value pairs in hte parameters object.

Ex.

          resolver: {
            name: 'flowed::Conditional',
            params: { condition: 'intervalsCreated', trueResult: 'This is the text for true' , falseResult: 'This is the text for false' },
            results: {onTrue: 'ontrue', onFalse: 'onfalse'},
          },

And/or also being able to reference values in the context object

Ex.

        resolver: {
          name: 'flowed::Conditional',
          params: { condition: 'intervalsCreated', trueResult: 'context.context_true' , falseResult: 'context.context_false' },
          results: {onTrue: 'ontrue', onFalse: 'onfalse'},
        },

Use a named function or lambda as resolver, intended to be used when it's better to create a class.

When using an async resolver which uses the fetch method to access an external endpoint the running flow is immediately interrupted and returns the control to the caller function without completing the tasks.

export function query_similar(query: string, filters: string) {
    return new Promise(async (resolve, reject) => {
        try {
            /* Call Clean API on the Front End API to reload the definition */
            const similar = "https://query-data.azurewebsites.net/api/similar?" + new URLSearchParams(
            {
                'op': "query",
                'query': query,
                "max_results": "10"
            });

           let response = await fetch(similar, {
                method: "GET",
                headers: {
                    "Content-Type": "application/json",
                }
            });

           const body = await response.json();
            
            if (body === undefined) {
                throw new Error(`Failed to call function: ${response.statusText}`);
            }
            resolve(body);
        } catch (error) {
            reject(error); // Reject the promise if an error occurs
        }
    });                           
}

async nlp_rank(item_id_field: string, records: any[], user_message:string) {
    if (isNotNull(records) && records.length > 0 && isNotNull(user_message)) {
      try {
        let id_list:string = records.map(record => record[item_id_field]).join(",");
        // call api to retrieve similarity ranking 
        const ranked_records = await query_similar(user_message, id_list);
        // merge arrays by document id
        let out_records = records.map((record, i) => Object.assign({}, record, ranked_records));     
        return out_records;
      } catch (error) {
        return;
      }
    }
  }

// This is the resolver class
export class ContentRank {
  async exec(params: ValueMap, context:ValueMap) {
    // simplified code

    records = await nlp_rank(item_id_field, input_records.records, userProfile.message);
    return { results: { records: records } };
  }
}

let results = await FlowManager.run(
        // The flow spec
        ret.strategy,          
        // The parameters
        ret.params,
        // The expected results
        [ out ],          
        // The resolvers mapping
        {
          load: Load as unknown as TaskResolverExecutor,
          filter: Filter as unknown as TaskResolverExecutor,
          contentrank: ContentRank as unknown as TaskResolverExecutor,
          similarrank: SimilarRank as unknown as TaskResolverExecutor,
          top: Top as unknown as TaskResolverExecutor,
          sort: Sort as unknown as TaskResolverExecutor,
          merge: Merge as unknown as TaskResolverExecutor
        },
        { webAPI: this.context, registry: this.registry, userManager},
      );

Without the async resolver the workflow completes correctly, I suspect I'm doing some mistake with await async into the chain of function calls but really struggling to find where it could be.

Add validations with the JSON-Schema standard as a built-in task, or as a part of tasks, to validate params and/or results.

Latest version of https://selecttransform.github.io/site/ offers support for "let" allowing to create local variables for the templates. Seems that the version on flowed is not updated to use such feature.
Would you consider adding it?

Have a built-in stop and pause resolver.
Ideas in code:

// Stops the flow execution
export class StopResolver {
public async exec(params: GenericValueMap, task: Task, flow: Flow): Promise {
const validSignals = ['term', 'kill'];

const signal = params.signal || 'term';

if (validSignals.indexOf(params.signal) === -1) {
  throw new Error(`Not a valid flow termination signal: ${params.signal}. Valid signals are: [${validSignals.join(', ')}].`);
}

// @todo implement flow.term()
// @todo implement flow.stop()
const flowResult = await flow[signal]();

return { results: flowResult };

}
}

Create a built-in task resolver to repeat a task execution using different params each time.
The input of the resolver would be an array of params.
The resolver would execute input.length times.
The output would be the array of results ordered in the same order as the params in the input array.

Those resources are not necessarily "parameters".

Be able to use build-in resolvers without passing them in the mapping when running the flow.

Right now, when executing the flow, we specify the desired results in the third parameter, for example

const response = await FlowManager.run(
      flowDefinition,
      parameters,
      ['myResponse'],
      resolvers,
);

But, when for whatever reason (for example a cyclic flow or and unintended incorrect flow), the flow ends and it does not have a myResponse property.

It would be ideal if you can notify of such cases so the rest of the code can react accordingly.

getDate: {
      provides: ['date'],
      resolver: {
        name: 'flowed::Echo',
        params: { in: { value: new Date() } },
        results: { out: 'date' },
      }
},

In the above configuration, what is the difference between provides and results ? Is it about task level and resolver level configuration?

Warn the user in the console when asking for a expected result that's not provided by any task.

It would be ideally to have the ability to pass some values for the tasks in the definition.

const flowDefinition = {
  tasks: {
    A: {
      requires: ['param1'],  
      provides: ['response'],
      resolver: {
        name: 'direct',
        params: { 
          param1: 'param1', // this one will be provided in the "run" method second parameter.
          param2: {value: '123'} // this one is directly defined in the flow. 
        },
        results: { b: 'response' },
      },
    },
  },
}

The idea is that those params are visible to the resolver of the ArrayMap and not necessarily taken from the array being iterated.

When specifying a flow with sub-flow(s), it is impossible to specify the resolvers in the parameter dynamically. So if the resolvers could be inherited from the outside flow it would be enough to solve this problem.

When a task spec has the field "requires" empty ([]), it would be good if it can be omitted. The same for "provides".

When any of them are not present, it would be assumed empty array.

I have a use case where I need to support conditional branching or invoking a resolver based on some condition. For example:-

resolverA() {
    api_call.then(()=>{
        //business logic
    }).catch(()=>{
        //invoke resolverB 
    })
}

Details on console

(node:5649) UnhandledPromiseRejectionWarning: #<Error>
(node:5649) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:5649) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Add a built-in task to merge objects.
Take into account precedence when fields are repeated in both objects.
Take into account merging more than 2 objects.

Honor printf formatting on calls to debug

It would be convenient to have a way to add an extra namespace to the calls to debug, in order to better filter the logs using the DEBUG variable.

Provide a built-in resolver to call a rest API.

Optional params pre-processing to make possible some simple processing without adding more tasks.
Examples of processing:

• Extract a field from an object
• Create an object from a value
• Create a string from a value
• Convert an object into another one