DEV Community: Shubham Kadam

NestJS: Mocking Databases for Efficient Tests

Shubham Kadam — Sat, 04 Nov 2023 11:02:26 +0000

Introduction

In NestJS, a popular Node.js framework, unit testing plays a crucial role in maintaining the reliability and quality of your codebase.

One common challenge when writing unit tests for NestJS applications is dealing with database interactions, particularly when using TypeORM as the Object-Relational Mapping (ORM) library or Mongoose module for MongoDB. It's essential to isolate your tests from the actual database to make them fast, reliable, and independent of external dependencies.

To address this challenge, you need to mock database calls in your unit tests. This involves simulating database interactions without actually hitting the database. By doing so, you can control the data used in your tests, improve test performance, and ensure that your tests remain consistent, even if the database schema or content changes.

In our upcoming blog post, we will explore the techniques and best practices for effectively mocking Mongoose database calls in NestJS unit tests, enabling you to write tests that are efficient, maintainable, and dependable.

Prerequisite

Since our primary focus here is to talk about unit tests and database mocking, this post will assume that you have a NestJS project setup ready, with one or more endpoints communicating with underlying Mongo database (or it could be any other SQL/NoSQL db).

Lets get started

Consider we have an Order management system, so it would naturally have an orders module which handles orders. In NestJS, orders controller will create api endpoints to allow users to perform db operations.

orders.controler.ts

import {
  Controller,
  Get,
  UseFilters,
  UseInterceptors,
  Post,
  Patch,
  Delete,
  Body,
  Param,
  Query,
  ParseIntPipe,
  DefaultValuePipe,
} from '@nestjs/common';
import {ApiBearerAuth, ApiQuery, ApiTags} from '@nestjs/swagger';
import {OrdersService} from './orders.service';
import {Order} from './schemas/order.schema';
import {CreateOrderDto} from './dto/create-order.dto';
import {UpdateOrderDto} from './dto/update-order.dto';

@ApiBearerAuth()
@ApiTags('orders')
@Controller('orders')
export class OrdersController {
  constructor(private readonly ordersService: OrdersService) {}

  /**
   * /POST endpoint
   * Used to add new order info
   * @param {CreateOrderDto} createOrderDto
   */
  @Post()
  async create(@Body() createOrderDto: CreateOrderDto): Promise<Order> {
    return await this.ordersService.create(createOrderDto);
  }

  /**
   * /GET endpoint
   * Used to get all orders data
   */
  @Get('all')
  async findAll(): Promise<{data: Orders[]}> {
    return await this.ordersService.findAll();
  }

  /**
   * /GET endpoint
   * Used to get order data by id
   * @param {string} id
   */
  @Get(':id')
  async findOne(@Param('id') id: string): Promise<Order> {
    return await this.ordersService.findOne(id);
  }

  /**
   * /PATCH endpoint
   * Used to update order info
   * @param {string} id
   */
  @Patch(':id')
  async update(@Param('id') id: string, @Body() updateOrderDto: UpdateOrderDto): Promise<Order> {
    return await this.ordersService.update(id, updateOrderDto);
  }

  /**
   * /DELETE endpoint
   * Used to delete order
   * @param {string} id
   */
  @Delete(':id')
  async delete(@Param('id') id: string): Promise<Order> {
    return await this.ordersService.delete(id);
  }
}

Since controller does not have any databse calls, writing unit test for it is straight forward.

orders.controller.spec.ts

import {Test, TestingModule} from '@nestjs/testing';
import {LoggerModule} from 'nestjs-pino';
import {OrdersController} from './orders.controller';
import {OrdersService} from './orders.service';
import {mockOrder, mockId} from '../utils/test-utils';

const mockId = '123';
const mockOrder: CreateOrderDto = {
  // ...fake order values
}

const mockOrderService = {
  create: jest.fn().mockReturnValue(mockOrder),
  findAll: jest.fn().mockReturnValue([mockOrder]),
  findOne: jest.fn().mockReturnValue(mockOrder),
  update: jest.fn().mockReturnValue(mockOrder),
  delete: jest.fn().mockReturnValue(mockOrder),
};
describe('OrderController', () => {
  let controller: OrdersController;
  let service: OrdersService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [LoggerModule.forRoot()],
      controllers: [OrdersController],
      providers: [
        {
          provide: OrdersService,
          useValue: mockOrderService,
        },
      ],
    }).compile();

    controller = module.get<OrdersController>(OrdersController);
    service = module.get<OrdersService>(OrdersService);
  });

  afterEach(() => {
    jest.clearAllMocks();
  });

  it('should be defined', () => {
    expect(controller).toBeDefined();
  });

  it('should create order data', async () => {
    const expectedOutput = await controller.create(mockOrder);
    expect(service.create).toHaveBeenCalledTimes(1);
    expect(service.create).toHaveBeenCalledWith(mockOrder);
    expect(expectedOutput).toEqual(mockOrder);
  });

  it('should find all order data', async () => {
    const expectedOutput = await controller.findAll();
    expect(service.findAll).toHaveBeenCalledTimes(1);
    expect(expectedOutput).toEqual([mockOrder]);
  });

  it('should find order data by id', async () => {
    const expectedOutput = await controller.findOne(mockId);
    expect(service.findOne).toHaveBeenCalledTimes(1);
    expect(service.findOne).toHaveBeenCalledWith(mockId);
    expect(expectedOutput).toEqual(mockOrder);
  });

  it('should update order data by id and payload', async () => {
    const expectedOutput = await controller.update(mockId, mockOrder);
    expect(service.update).toHaveBeenCalledTimes(1);
    expect(service.update).toHaveBeenCalledWith(mockId, mockOrder);
    expect(expectedOutput).toEqual(mockOrder);
  });

  it('should delete order data by id', async () => {
    const expectedOutput = await controller.delete(mockId);
    expect(service.delete).toHaveBeenCalledTimes(1);
    expect(service.delete).toHaveBeenCalledWith(mockId);
    expect(expectedOutput).toEqual(mockOrder);
  });
});

Order module's service file is responsible for handling business logic, which also means managing calls to mongo database.

From the documentation

Model injection
With Mongoose, everything is derived from a Schema. Each schema maps to a MongoDB collection and defines the shape of the documents within that collection. Schemas are used to define Models. Models are responsible for creating and reading documents from the underlying MongoDB database.

Below, we have an Order schema and we are going to define a model using this schema. This model is responsible for performing read/write operations in MongoDB.

orders.service.ts

import {Injectable, NotFoundException} from '@nestjs/common';
import {InjectModel} from '@nestjs/mongoose';
import {Model} from 'mongoose';
import {Order, OrderDocument} from './schemas/order.schema';
import {CreateOrderDto} from './dto/create-order.dto';
import {UpdateOrderDto} from './dto/update-order.dto';
import {IOrders} from '../interface/data-interface/orders.interface';

// fields to exclude in api response
export const EXCLUDE_FIELDS = '-_id -__v';

@Injectable()
export class OrdersService {
  constructor(@InjectModel(Order.name) private orderModel: Model<OrderDocument>) {}

  async create(createOrderDto: CreateOrderDto): Promise<Order> {
    const order = await this.orderModel.create(createOrderDto);
    return order;
  }

  async findAll(): Promise<IOrders> {
    const data = await this.orderModel.find().select(EXCLUDE_FIELDS).exec();
    return {data};
  }

  async findOne(orderId: string): Promise<Order> {
    const doc = await this.orderModel.findOne({orderId}).select(EXCLUDE_FIELDS).exec();
    if (!doc) throw new NotFoundException(`Order with id '${orderId}' not found!`);
    return doc;
  }

  async update(orderId: string, updateOrderDto: UpdateOrderDto): Promise<Order> {
    const doc = await this.orderModel.findOne({orderId}).exec();

    if (!doc) throw new NotFoundException(`Failed to update order! Order with id '${orderId}' not found.`);

    Object.assign(doc, updateOrderDto);
    const order = await doc.save();
    return order;
  }

  async delete(orderId: string): Promise<Order> {
    const doc = await this.orderModel.findOneAndDelete({orderId}).select(EXCLUDE_FIELDS).exec();
    if (!doc) throw new NotFoundException(`Failed to delete order! Order with id '${orderId}' not found.`);
    return doc;
  }
}

Like I said before, we have defined a Mongoose Model orderModel which performs db operations and this is the model we are going to mock while writing unit test

Here's how you would mock this model with all the necessary methods

class MockedOrderModel {
  constructor(private _: any) {}
  new = jest.fn().mockResolvedValue({});
  static save = jest.fn().mockResolvedValue(mockOrder);
  static find = jest.fn().mockReturnThis();
  static create = jest.fn().mockReturnValue(mockOrder);
  static findOneAndDelete = jest.fn().mockImplementation((id: string) => {
    if (id == mockIdError) throw new NotFoundException();
    return this;
  });
  static exec = jest.fn().mockReturnValue(mockOrder);
  static select = jest.fn().mockReturnThis();
  static findOne = jest.fn().mockImplementation((id: string) => {
    if (id == mockIdError) throw new NotFoundException();
    return this;
  });
}

And since we are mocking the DB methods, when a save method gets called, save method from MockedOrderModel would be invoked. We have also added few more conditions while mocking these methods to invoke erroneous conditions and have better test coverage.

We need to pass MockedOrderModel in Test.createTestingModule as a provider and we are all set.

Note: Refer NestJS testing doc for more info on Test module

Here's the unit test file
orders.service.spec.ts

import {Test, TestingModule} from '@nestjs/testing';
import {getModelToken} from '@nestjs/mongoose';
import {HttpStatus, NotFoundException} from '@nestjs/common';
import {OrdersService} from './orders.service';
import {Order} from './schemas/order.schema';

const mockOrder = {} as Order;
const mockAllOrder = {data: []};
const mockId = '123';
const mockIdError = 'error';
export const EXCLUDE_FIELDS = '-_id -__v';

class MockedOrderModel {
  constructor(private _: any) {}
  new = jest.fn().mockResolvedValue({});
  static save = jest.fn().mockResolvedValue(mockOrder);
  static find = jest.fn().mockReturnThis();
  static create = jest.fn().mockReturnValue(mockOrder);
  static findOneAndDelete = jest.fn().mockImplementation((id: string) => {
    if (id == mockIdError) throw new NotFoundException();
    return this;
  });
  static exec = jest.fn().mockReturnValue(mockOrder);
  static select = jest.fn().mockReturnThis();
  static findOne = jest.fn().mockImplementation((id: string) => {
    if (id == mockIdError) throw new NotFoundException();
    return this;
  });
}
describe('OrdersService', () => {
  let service: OrdersService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        OrdersService,
        {
          provide: getModelToken(Order.name),
          useValue: MockedOrderModel,
        },
      ],
    }).compile();

    service = module.get<OrdersService>(OrdersService);
  });

  afterEach(() => {
    jest.clearAllMocks();
  });

  it('should be defined', () => {
    expect(service).toBeDefined();
  });

  it('should create new order', async () => {
    const expectedOutput = await service.create(mockOrder);
    expect(MockedOrderModel.create).toHaveBeenCalledTimes(1);
    expect(expectedOutput).toEqual(mockOrder);
  });

  it('should find all orders', async () => {
    const expectedOutput = await service.findAll();
    expect(MockedOrderModel.find).toHaveBeenCalledTimes(1);
    expect(MockedOrderModel.exec).toHaveBeenCalledTimes(1);
    expect(MockedOrderModel.save).toHaveBeenCalledTimes(1);
    expect(MockedOrderModel.save).toBeCalledWith(EXCLUDE_FIELDS);
    expect(expectedOutput).toEqual(mockAllOrder);
  });

  describe('Get Order', () => {
    it('should find order by id', async () => {
      const expectedOutput = await service.findOne(mockId);
      expect(MockedOrderModel.findOne).toHaveBeenCalledTimes(1);
      expect(MockedOrderModel.findOne).toBeCalledWith(mockId);
      expect(MockedOrderModel.exec).toHaveBeenCalledTimes(1);
      expect(MockedOrderModel.save).toHaveBeenCalledTimes(1);
      expect(MockedOrderModel.save).toBeCalledWith(EXCLUDE_FIELDS);
      expect(expectedOutput).toEqual(mockOrder);
    });

    it('should throw NotFoundException', async () => {
      try {
        await service.findOne(mockIdError);
      } catch (error: any) {
        expect(error.message).toEqual('Not Found');
        expect(error.status).toEqual(HttpStatus.NOT_FOUND);
        expect(error.name).toEqual('NotFoundException');
      }
    });
  });
  // ... unit test for update and delete functionality will have similar implementation
});

Conclusion:

Unit testing is a vital part of NestJS development. Mocking database calls is key to making your tests fast, reliable, and independent of external dependencies. Whether you're using TypeORM or Mongoose for MongoDB, the techniques shared in this post help you write efficient, maintainable, and dependable unit tests. By mastering database mocking, you're enhancing the quality and resilience of your NestJS applications. Happy testing!

NestJS Custom Payload Validation

Shubham Kadam — Tue, 15 Mar 2022 08:52:57 +0000

This is a follow-up post to my previous blog NestJS Payload Validation. In this blog-post I’ll talk about how we can implement our own custom payload validation. That is, there might be a scenario where you would like to add your own logic to validate particular payload value and the class-validator package provides us with this ability.

Before we begin, here's the github repo for the project
which has below mentioned code examples.

In order to perform custom payload validation we need to implement ValidatorConstraintInterface interface and its validate method and post implementing the interface we need to apply @ValidatorConstraint decorator to the class (which implements the interface). For instance, lets say we have deployed an api which expects payload with employee’s age information, here’s an example:

{
  "age": 24
}

And the DTO for the same:

export class EmployeeAgeDetails {
  age: number;
}

The age property needs to have some restriction, like for instance, age should be an integer value and should be greater than (>=) 18 and less than (<=) 65.

I know in real world we would expect much more info than just employee’s age, but lets keep things simple so we understand better and quicker!

Fyi, we can perform the above mention validation directly with validation decorators provided by the class-validator as well. Please checkout my NestJS Payload Validation blog for example.

Lets see some code examples to demonstrate above case:

The class which implements ValidatorConstraintInterface interface, lets call it CustomAgeLimitValidator, here’s code for the same:

import {
  ValidatorConstraint,
  ValidatorConstraintInterface,
} from 'class-validator';

@ValidatorConstraint({ name: 'CustomAgeLimitValidator', async: false })
export class CustomAgeLimitValidator implements ValidatorConstraintInterface {
  validate(value: any): boolean {
    // Add validation logic here
    if (value < 18 || value > 65) return false;
    return true;
  }
}

The name argument in @ValidatorConstraint decorator represents the ‘error type’ and if not provided, the value will be generated automatically. The validation can also be asynchronous, hence the param async is used in decorator @ValidatorConstraint (please checkout the documentation for more info).

Here’s how you apply the CustomAgeLimitValidator validator to EmployeeAgeDetails DTO:

import {
  IsInt,
  IsNotEmpty,
  Validate,
} from 'class-validator';
import { CustomAgeLimitValidator } from '../custome-payload-validators/age-limit-validator';

export class EmployeeAgeDetails {
  @IsNotEmpty()
  @IsInt()
  @Validate(CustomAgeLimitValidator)
  age: number;
}

The validation decorators provided by the class-validator provides us with the ability to pass our own error message. In our case, here’s how we will do it:

@Validate(CustomAgeLimitValidator, {message: 'Age limit violation! Employee age should be between 18 and 65 years'})

With these changes if we try to feed our endpoint with below payload:

{
  "age": 16
}

It would cause below error:

{
    "statusCode": 400,
    "message": [
        "Age limit violation! Employee age should be between 18 and 65 years"
    ],
    "error": "Bad Request"
}

Along with the ability to provide error message while applying validation decorators we can also provide default error message incase we forget or don’t feel the need to provide error message while applying decorator. To implement this case, we need to add optional defaultMessage method inside our CustomAgeLimitValidator class. Here’s the code example:

import {
  ValidatorConstraint,
  ValidatorConstraintInterface,
  ValidationArguments,
} from 'class-validator';

@ValidatorConstraint({ name: 'CustomAgeLimitValidator', async: false })
export class CustomAgeLimitValidator implements ValidatorConstraintInterface {
  validate(value: any): boolean {
    // Add validation logic here
    if (value < 18 || value > 65) return false;
    return true;
  }

  // optional method
  defaultMessage(args: ValidationArguments) {
    // Provide default error message if validation failed
    return `Age value ${args.value} caused age limit violated! Employee age should be between 18 and 65 years`;
  }
}

And if we feed the api with invalid age value

{
  "age": 16
}

with above changes, the output error message would be:

{
    "statusCode": 400,
    "message": [
        "Age value 16 caused age limit violation! Employee age should be between 18 and 65 years"
    ],
    "error": "Bad Request"
}

And we are done! Hope you guys enjoyed it.

Stay tuned, Thank You!

NestJS Payload Validation

Shubham Kadam — Wed, 02 Mar 2022 14:43:16 +0000

While working on building APIs, we started talking about how we can validate user input and since we are using NestJS, I started looking into in-house solution for the same. So, I started going through NestJS documentation, looking for a potential solution.

The NestJS documentation is very well written, and I was able to come up with a solution using ValidationPipe in couple of days. But, to build something simple, going through the documentation becomes a bit tedious. The aim of this blog post is to help you get started (with input validation) quickly if you are trying to build something less complex or rather, you can consider this as a beginner’s guide.

Note:
Since this blog is not about NestJS itself, we will proceed, assuming you know how to write microservices using NestJS and what DTOs are.

Before we begin, here’s the link to the github repo for the NestJS project which has the below mentioned code example for you to try locally.

Now, lets assume that we have written a microservice that handles employee details and you want to add new employee details via POST request. The request payload would look like:

{
   "name":"Peter Griffin",
   "age":44,
   "address":{
      "country":"US",
      "state":"California",
      "city":"Los Angeles",
      "street":"Alameda Street",
      "flatNo":12
   },
   "projects":[
      "CustomerInsights",
      "Matter"
   ],
   "workExperience":[
      {
         "orgName":"SomeFamousOrg",
         "exp":5
      },
      {
         "orgName":"SomeSuperFamousOrg",
         "exp":7
      }
   ]
}

DTOs for above payload would look like below:

export class Address {
  country: string;
  state: string;
  city: string;
  street: string;
  flatNo: number;
}

export class WorkExperience {
  orgName: string;
  exp: number;
}

export class EmployeeDetails {
  name: string;
  age: number;
  address: Address;
  projects: string[];
  workExperience: WorkExperience[];
}

Below are the validations we need to apply to the mentioned payload:

Employee name should only contain characters i.e. numeric values and symbols not allowed.
age should be integer value and greater than (>=) 18 and less than (<=) 65.
address has below restrictions:
1. country, state, street and city should only consist of characters.
2. flatNo should be integer
projects should be an array of string.
All the mentioned details must be provided i.e. empty values not allowed.
There should be length related restriction on string values.

To get this job done, we will use validation decorators provided by the class-validator package.

Installation command for `class-validator` package:

~ npm install class-validator --save
The DTOs after changes (along with the imports) would look like below:

import {
  ArrayNotEmpty,
  IsArray,
  IsInt,
  IsNotEmpty,
  IsString,
  Matches,
  MaxLength,
  ValidateNested,
  Min,
  Max,
  IsNumber,
} from 'class-validator';
import { Type } from 'class-transformer';

export class Address {
  @IsString()
  @IsNotEmpty()
  @Matches('^[a-zA-Z\\s]+$')
  @MaxLength(15)
  country: string;

  @IsString()
  @IsNotEmpty()
  @Matches('^[a-zA-Z\\s]+$')
  @MaxLength(15)
  state: string;

  @IsString()
  @IsNotEmpty()
  @Matches('^[a-zA-Z\\s]+$')
  @MaxLength(15)
  city: string;

  @IsString()
  @IsNotEmpty()
  @Matches('^[a-zA-Z\\s]+$')
  @MaxLength(20)
  street: string;

  @IsInt()
  @IsNotEmpty()
  flatNo: number;
}

export class WorkExperience {
  @IsString()
  @IsNotEmpty()
  @Matches('^[a-zA-Z0-9\\s]+$')
  @MaxLength(30)
  orgName: string;

  @IsNumber({ maxDecimalPlaces: 2 })
  @IsNotEmpty()
  exp: number;
}

export class EmployeeDetails {
  @IsNotEmpty()
  @IsString()
  @Matches('^[a-zA-Z\\s]+$')
  @MaxLength(50)
  name: string;

  @IsNotEmpty()
  @IsInt()
  @Min(18)
  @Max(65)
  age: number;

  @ValidateNested()
  @Type(() => Address)
  @IsNotEmpty()
  address: Address;

  @IsArray()
  @ArrayNotEmpty()
  @IsString({ each: true })
  @Matches('^[a-zA-Z0-9\\s]+$', undefined, { each: true })
  @MaxLength(30, { each: true })
  projects: string[];

  @IsArray()
  @ArrayNotEmpty()
  @ValidateNested({ each: true })
  @Type(() => WorkExperience)
  workExperience: WorkExperience[];
}

Explanation

The validation for input values of name and age is straightforward. Let’s look at the attributes which are a bit complex.

projects:

projects attribute is of type array i.e. array of string, so the decorators @IsArray() and @ArrayNotEmpty() were applied accordingly.

But, how do we validate values inside the array? For example, if we have an array:

projects: [‘CustomerInsights’, ‘DemoPipeline’]

How do we validate values ‘CustomerInsights’ and ‘DemoPipeline’ individually? How do we make sure that they satisfy all the necessary restrictions?

The answer is, by passing validation option each: true inside the desired decorator.

why? Because,

If your field is an array and you want to perform validation of each item in the array you must specify a special each: true decorator option.
NestJS Documentation

We want the array values to be string, so we use @IsString() decorator and pass argument each: true to it, i.e. @IsString({ each: true }). Similar approach is applied to other decorators like @Matches() and @MaxLength() as well.

address:

The address attribute is not of primitive type, but instead, is an object which consists of nested object. Due to this, we applied @ValidateNested() decorator along with @Type() decorator, to indicate object type and applied validation separately to each of its nested objects (refer class Address).

workExperience:

The workExperience is similar to the address attribute as far as its type is concerned, the only difference is, instead of consisting of nested objects, it represents ‘array of nested objects‘, and hence, we added the each: true option to the @ValidateNested() decorator i.e.@ValidateNested({ each: true }) and this will ensure that all the nested objects are validated.

And we are done! Hope you guys enjoyed it.
In my next blog, I’ll talk about how to perform custom payload validation.

Please do checkout the project's github repo

Stay tuned, Thank You!

DigDag - Schedule a Job(workflow) multiple times on same day

Shubham Kadam — Sat, 15 Feb 2020 18:55:22 +0000

Hey folks! So, I had a task of scheduling a Dashboard execution daily at 12.00 pm and 4.00 pm and was supposed to use DigDag Job Scheduler. But, after spending quite some time on DigDag’s documentation, I couldn’t find anything relevant as per my requirement. Hence, I decided to try a workaround.

"Instead of scheduling the Dashboard using a single workflow (the *.dig file), I can import/include the workflow into another workflow(s) and schedule it as per my need."

For example:

Note: The below example is demonstrated on Ubuntu 18.04 (Linux). Please refer DigDag’s documentation for other platform-specific commands.

Lets generate a sample digdag project schedule-demo using command:

$ digdag init schedule-demo

The above command will create a workflow schedule-demo.dig in schedule-demo directory/project with contents:

timezone: UTC


+setup:

 echo>: start ${session_time}


+disp_current_date:

 echo>: ${moment(session_time).utc().format(‘YYYY-MM-DD HH:mm:ss Z’)}


+repeat:

 for_each>:

 order: [first, second, third]

 animal: [dog, cat]

 _do:

 echo>: ${order} ${animal}

 _parallel: true


+teardown:

 echo>: finish ${session_time}

Let's schedule the above workflow for every one and two minutes on same day using file one_minute.dig and two_minutes.dig workflow.

Create workflows one_minute.dig and two_minutes.dig in the project schedule-demo with below-mentioned contents:

Workflow one_minute.dig:

!include : ‘schedule-demo.dig’

schedule:

 minutes_interval>: 1

Workflow two_minute.dig:

!include : ‘schedule-demo.dig’

schedule:

 minutes_interval>: 2

Now change your current working directory to schedule-demo using the command:

$ cd {current_path}/schedule-demo/

then push the project schedule-demo to digdag server using the command:

$ digdag push schedule-demo

(Note: On local Ubuntu setup, to start digdag server execute command ‘digdag server’ on the terminal)

If you are outside the project directory and want to push project use command:

$ digdag push schedule-demo --project /{path}/schedule-demo  --revision schedule-demo-v1

{path} => path to the schedule-demo project

Then, launch a browser (any) and add URL ‘http://localhost:65432/’ and under Workflow tab you will see the result similar to below image (you will have to wait for at least 5–6 minutes to get similar output as of mine):

If you observe the image, the output with ID 2 and ID 5 has 2 minutes difference (refer column 'Last Attempt' ) and the value of Workflow is two-minute. You will find similar result for the one-minute workflow (i.e. the execution time difference between every present and next workflow attempt will be 1 minute).

P.S. There could be different ways to achieve the result demonstrated in the above example. This is just one of those :)

If you enjoyed this blog, share it with your friends!

Thank-You for reading!

Sources:

https://www.digdag.io/
https://docs.digdag.io/getting_started.html
https://docs.digdag.io/workflow_definition.html?highlight=include#include-another-file