Allow extending a serve handler by overriding the existing isProduction

[jpwilliams]

Summary

Allows users to override the existing isProduction check performed by serve handlers, providing their own value (or dynamic value).

Note

Not specifying the value--or if the value or dynamic value is undefined--will ensure the SDK falls back to using the current production checks.

import { functions, inngest } from "@/inngest";
import { serve } from "inngest/next";

export default serve({
  client: inngest,
  functions,
  // set a static value
  isProduction: false,
});

import { functions, inngest } from "@/inngest";
import { serve } from "inngest/next";

export default serve({
  client: inngest,
  functions,
  // or use an environment variable check
  isProduction: process.env.MY_CUSTOM_VAR === "yes",
});

import { functions, inngest } from "@/inngest";
import { serve } from "inngest/next";

export default serve({
  client: inngest,
  functions,
  // or use a function to calculate the value dynamically
  isProduction: async () => {
    const amIProd = await makeRequestToCheck();
    return amIProd;
  },
});

It's specified on the serve() handler as they already need to be able to decide for themselves whether they're in production mode, as some pieces of the puzzle (like environment variables) are not available until the request enters the system.

Therefore, this is the first part of allowing users to extend existing serve handlers to override pieces of functionality such as production checks, URL creation, or accessing environment variables.

Checklist

• Added a docs PR that references this PR
• Added unit/integration tests
• Added changesets if applicable

Related

• Intended to be a slightly less invasive Remove prod check to enable integration tests with dev server #424

[changeset-bot]

⚠️ No Changeset found

Latest commit: caf0316

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[inngest-release-bot]

A user has added the prerelease/inngest label, so this PR will be published to npm with the tag pr-425. It will be updated with the latest changes as you push commits to this PR.

You can install this prerelease version with:

npm install inngest@pr-425

The last release was built and published from caf0316.

[djfarrelly]

I wonder if this is a weird DX that this is isProduction which the dev then may only want sometimes to opt-out of production checks, but they may want the production checks that already exist by default.

Thinking through the usage of this for integration testing, you might see this and say, if I set this to false, that should make it not act as it was in prod, but that' snot true due to the check in the comm handler's constructor:

export default serve({
  client: inngest,
  functions,
  // Setting false will not work - I want to opt-out, not opt in
  isProduction: !!process.env.INTEGRATION_TEST ? 
    false : 
    // I'd still want to default NODE_ENV check to work
    // so I don't want to say if not integration test, then true
    undefined, 
});

INTEGRATION_TEST=1 node ./index.js # this won't work right if NODE_ENV=production

So then to solve this in the current code where there is the options.isProduction check within the comm handler's constructor, you'd have to make it a function:

export default serve({
  client: inngest,
  functions,
  // Function has to return undefined to fallback to the default NODE_ENV check
  // w/ the nullish coalescing in handleAction
  isProduction: () =>  !!process.env.INTEGRATION_TEST ? 
    false : 
    undefined, 
});

INTEGRATION_TEST=1 node ./index.js

It feels a bit cumbersome to basically just opt-out of the signing key security checks. Our customer had an interesting thought of just making this more explicit like disableProductionChecks: boolean which is more of an opt-in than the current approach.

export default serve({
  client: inngest,
  functions,
  // Some positives:
  // - The user can customize this as needed
  // - It's less clever - more straightforward what this does
  // - It clearly demonstrates some sort of risk if you opt-out
  disableProductionChecks: () =>  !!process.env.INTEGRATION_TEST
});

Sharing this in the PR for transparency/posterity 😄

[IGassmann]

@jpwilliams, a user tried this feature and experienced some issues. Linking the conversation..

[jpwilliams]

Thanks, @IGassmann.

Closing this now. Superseded by #488.