"Must supply cloud_name" error when using Cloudinary

I am using Cloudinary to host some images which I need to display in a Next.js application. I'm testing this locally with npm run dev.

import Link from '/src/Link';

import { Cloudinary } from '@cloudinary/url-gen';
import { scale } from "@cloudinary/url-gen/actions/resize";

const cld = new Cloudinary({
    cloud: {
        cloudName: process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME,
    },
    url: {
        secure: true // force https
    }
});

export default function QImage({ info }) {
    const thumb = cld.image(info.public_id).resize(scale().width(200));
    const img = cld.image(info.public_id).resize(scale().width(1600));
    const size = `${info.width}-${info.height}`

    return (
        <Link href={img.toURL()} color="secondary" key={info.asset_id} data-lg-size={size}>
            <img src={thumb.toURL()} />
        </Link>
    )
}

Intermittently, rendering of the page will fail with this error:

error - Error: Must supply cloud_name
    at getProperError (/proj/node_modules/next/dist/lib/is-error.js:41:12)
    at DevServer.renderToResponseImpl (/proj/node_modules/next/dist/server/base-server.js:1343:53)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async DevServer.pipeImpl (/proj/node_modules/next/dist/server/base-server.js:630:25)
    at async Object.fn (/proj/node_modules/next/dist/server/next-server.js:1144:21)
    at async Router.execute (/proj/node_modules/next/dist/server/router.js:315:32)
    at async DevServer.runImpl (/proj/node_modules/next/dist/server/base-server.js:604:29)
    at async DevServer.run (/proj/node_modules/next/dist/server/dev/next-dev-server.js:922:20)
    at async DevServer.handleRequestImpl (/proj/node_modules/next/dist/server/base-server.js:533:20) {
  digest: undefined
}

This stack is not helpful. I have confirmed that the correct cloudName is in the environment and being passed to the config. What else could cause this?

UPDATE: When this happens, visiting the index page of the site (with only Cloudinary Admin API calls) seems to fix it. If I then return to the page which loads the component excerpted here, the error goes away.

Could it be to do with some conflict between the two Cloudinary configuration setups? My other page is using resources calls from the v2 API like this:

import { v2 as cloudinary } from 'cloudinary'

cloudinary.config({ 
  cloud_name: 'sample', 
  api_key: '874837483274837', 
  api_secret: 'a676b67565c6767a6767d6767f676fe1',
  secure: true
});

Solution

The problem was that I wasn't initializing the library in every situation. Instead of having to remember to call cloudinary.config() before each use, sometimes multiple times per file, I now have a separate file:

src/cloudinary.js

import cloudinaryLib from 'cloudinary'

const cloudinary = cloudinaryLib.v2

cloudinary.config({
  cloud_name: process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME,
  api_key: process.env.CLOUDINARY_KEY,
  api_secret: process.env.CLOUDINARY_SECRET,
  secure: true,
})

export default cloudinary

And then importing is both easy and always fully configured:

import cloudinary from '/src/cloudinary'

// ...

cloudinary.url(/* etc */)