Fueling Curiosity, One Insight at a Time

Error Monitoring in Bugsnag works similar to Sentry and the commonly used method is bugsnag.notify() . It also takes an error object and captures it as an event. And we can set it up for different environments by using ENV (similar to sentry) or manually configure it as well.
FYI: Sentry has a broader approval by developers.

EG:

try {
  // Some code here
} catch (error) {
 bugsnag.notify(
      new Error(`Error ${error} while sending Standup popup`)
    );
}

In Sentry we have two methods available, captureException() and captureMessage().
1. captureException() method is used to explicitly report errors and exceptions. We can pass an Error object to captureException() to capture it as an event in Sentry.
2. captureMessage() method is used to capture a simple message for debugging purposes. Typically, messages captured with captureMessage() are not emitted as events. We can additionally add severity level to this. Available levels are "fatal", "error", "warning", "log", "info", and "debug".

Local storage does not work right off the bat when we render a web page within an App. App Dev will have to ensure that DOM storage is enable for it to work.

Mocking useSWR directly in test cases is a little complicated and even not recommended at some places.
So the ideal way to do it is using a library Mock Service Worker. Here are the steps that helped me solve this.
1. Create a mock server using setupServer from msw/node:

const server = setupServer(
  rest.get(`/api/channels/C04UPJ9243E/members`, (req, res, ctx) => {
    return res(
      ctx.json({
        members: [{ name: "Sibtain", image: "abcd.jsp", id: 123 }],
      })
    );
  })
);

2. Start the server and after we run the test, close the server.

beforeAll(() => server.listen());
afterAll(() => server.close());

3. To ensure clean and isolated tests, reset the request handlers.

afterEach(() => server.resetHandlers());

Now our API connections are taken care of and we can render components and run the test cases.

test('render stuff, () => {
}

Resources: https://mswjs.io/

While writing Cypress test we generally create a cypress.env.json file to store the environment variables.

{
  "BASE_URL": "https://company.dev.com/",
  "USER_EMAIL": "ashwani@example.com",
  "USER_PASSWORD": "Test@12345",
}

To retrieve the value of our environment variable, we use the Cypress.env method in the test file.

const baseUrl = Cypress.env('BASE_URL');

That's all we need to do locally to use the env vars in our Cypress test.

Now for CI, we can save these environment variables as Github action secrets.

To make these environment variables accessible from Github action secrets to our test, we need to keep a few things in mind.

• Add a value of empty string to the env vars and expose the cypress.env.json file.

  {
       "BASE_URL": "",
       "USER_EMAIL": "",
       "USER_PASSWORD": "",
  }

• We need to add CYPRESS_ prefix to the env vars in the yml file.

   env:
       CYPRESS_BASE_URL: ${{ secrets.BASE_URL }}
       CYPRESS_USER_EMAIL: ${{ secrets.USER_EMAIL }}
       CYPRESS_USER_PASSWORD: ${{ secrets.USER_PASSWORD }}

Happy testing!

If Postgres logical replication is enabled via pglogical extension, below query can be used to check the size WAL Folder.
select sum(size) from pg_ls_waldir(); (Response to the query is in Bytes)

This is the folder where the WAL logs are stored, which is utilized for postgres data replication from master to slave. In case there is any lag or problems with replication the logs will get accumulating in the folder, spiking the disk storage and can cause downtime of the database it self.

In the first server-side rendering (SSR) page render, the router.query may not be populated immediately. To handle this scenario, we can add a check to ensure that the redirection happens only on the client-side, once the router.query values are available.

import { useEffect } from 'react';
import { useRouter } from 'next/router';

export const ResetPasswordPage = () => {
  const { push, query, isReady } = useRouter();
  const { username, code } = query as ResetPasswordPageQuery;
   ...
  useEffect(() => {
    if (isReady && (!username || !code)) {
      push('/login');
    }
  }, [isReady, username, code, push]);
  ...
};

Here the isReady property from useRouter is used to determine if the router is ready and router.query is populated.
This way, the initial SSR render won't trigger the redirection, and the user will be redirected to the login page only on the client-side if the necessary parameters are missing from the URL.

Tools discussed in todays session
1. https://ethereal.email/ - Email Testing
2. https://github.com/danmayer/coverband - Clean Up Legacy Unused Code
3. https://posthog.com/ - Product Analytics
4. https://miro.com/ - Collaboration Tool

Open PR from CLI
• brew install hub
• git config --global hub.protocol https
• hub pull-request (Will create PR for the current branch)

Term called fuzzy searching
fuzzy searching (more formally known as approximate string matching) is the technique of finding strings that are approximately equal to a given pattern (rather than exactly).