[BUG]: Backend crashes at startup when Cloudinary config is missing or invalid

[Mayur-Shashidhar]

Pre-checks

• I have searched for existing issues (open and closed)
• I am using the latest version of CertiNova
• I have checked the documentation for any relevant info

Issue Type

Platform Error (crash, freeze)

Environment

Local Development

Version / Commit ID

main (HEAD)

OS

macOS

Browser (if UI-related)

N/A

Current Behavior

When starting the backend (server.js), the process runs a Cloudinary smoke test and attempts to connect to MongoDB. In the current run, Cloudinary config prints as set but the server fails to connect to MongoDB with an invalid or missing MONGODB_URI. This causes the process to exit and the application never starts.

Expected Behavior

• Backend should clearly report a configuration error for MONGODB_URI but should not crash in a way that prevents helpful debugging logs.
• Preferably:
  • Startup should fail fast with a clear, handled error if required variables are missing (and documentation should reflect required vs optional).
  • Or allow startup to continue with reduced functionality if Cloudinary is optional (configurable by REQUIRE_CLOUDINARY), while failing fast for required dependencies like MongoDB.
• Error messages should suggest remediation steps (e.g., copy .env.example and fill MONGODB_URI).

Steps to Reproduce

1. From repository root:
   
   cd certinova-backend
   # Ensure Cloudinary vars may or may not be set; for this bug, ensure MONGODB_URI is missing or malformed
   unset MONGODB_URI
   npm run dev
   
2. Observe that Cloudinary test runs and then Node process exits with the MongoDB "Invalid scheme" error.

Alternative reproducible case (malformed URI):

export MONGODB_URI="not-a-mongo-uri"
npm run dev

Screenshots / Recordings

Logs/Errors

> certinova-backend@1.0.0 dev
> nodemon server.js

[nodemon] 3.1.10
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,cjs,json
[nodemon] starting `node server.js`
=== Cloudinary Configuration Test ===
Environment Variables:
Cloud Name: ✓ Set (your-cloudinary-cloud-name)
API Key: ✓ Set
API Secret: ✓ Set

✅ Cloudinary environment variables are set correctly!
==========================================

Error: Invalid scheme, expected connection string to start with "mongodb://" or "mongodb+srv://"
[nodemon] app crashed - waiting for file changes before starting...

Possible Solution (Optional)

Short-term fixes:

• Validate MONGODB_URI early and provide a clear, descriptive error message before attempting to connect.
• Wrap testCloudinaryConfig() and connectDB() startup calls in safe error handling so logs are clear and the application exit is controlled:
  • Example in server.js:

    try {
      await testCloudinaryConfig();
    } catch (err) {
      console.warn('Cloudinary config test failed:', err.message);
      // continue or exit depending on REQUIRE_CLOUDINARY
    }
    
    try {
      await connectDB();
    } catch (err) {
      console.error('MongoDB connection failed:', err.message);
      process.exit(1);
    }

• Add an env flag REQUIRE_CLOUDINARY (default false) to allow optional Cloudinary in dev.
• Improve documentation to state the required env vars for local/dev runs and provide example MONGODB_URI values (local and Atlas, redacted).

Medium-term fixes:

• Add integration/startup tests that assert controlled behavior when env vars are missing or malformed.
• Add a helpful health-check endpoint and/or a startup self-check script that returns a structured JSON explaining which dependencies are healthy/unhealthy.

Code of Conduct

• I agree to follow this project's Code of Conduct

[Mayur-Shashidhar]

@12fahed I would love to work on this under GSSoC 2026

[Tanisha-sharma7302]

I'd like to work on this issue as a GSSoC contributor. I plan to add proper validation for Cloudinary config at startup and handle missing/invalid credentials gracefully with a clear error message instead of crashing.

Kindly assign this to me!

[Sanskar-soni04]

Hi @12fahed! 👋

I'd love to work on this bug fix under GSSoC '26.

The fix involves:

• Validating MONGODB_URI early at startup with a clear, descriptive error message
• Wrapping testCloudinaryConfig() and connectDB() in proper try/catch blocks for controlled error handling
• Adding an optional REQUIRE_CLOUDINARY env flag for dev flexibility

I've gone through the issue thoroughly and have a clear approach ready. Could you please assign this to me? I'll have a PR up within 1–2 days. 🙏

[12fahed]

hey @Mayur-Shashidhar thanks for the suggestion, lemme know if you are still open to contribute

[Itsssaksham]

can you assign this issue to me ?

[arcgod-design]

Hi @12fahed! I'd love to work on this bug fix as part of SSoC '26.

My Approach:

• Add a startup validation function that checks all required Cloudinary environment variables (CLOUDINARY_CLOUD_NAME, CLOUDINARY_API_KEY, CLOUDINARY_API_SECRET) before initializing the server
• Return a clear error message listing exactly which config values are missing or invalid
• Wrap the Cloudinary client initialization in a try/catch block to prevent unhandled crashes
• Add a fallback or graceful degradation mode when Cloudinary is not configured (e.g., disable media upload features)
• Add unit tests to verify behavior with missing/invalid config

Could you please assign this to me (@arcgod-design)? Thank you!

[arcgod-design]

Hi @12fahed! I am participating in SSoC '26 and would love to work on this issue.

My approach:

• Add environment variable validation at startup in the backend entry point (e.g., server.js or app.js) to check that CLOUDINARY_CLOUD_NAME, CLOUDINARY_API_KEY, and CLOUDINARY_API_SECRET are all present and non-empty
• Throw a descriptive error (not a crash) with a clear message like "Missing Cloudinary config: CLOUDINARY_API_KEY is required" so developers can diagnose the issue immediately
• Optionally add a .env.example with all required Cloudinary config keys documented
• Add a basic startup test that validates the config validation logic

Could you please assign this issue to me? I'm ready to start immediately!