workflow 4.2.0-beta.72 → 4.2.0-beta.73

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -160,6 +160,12 @@ Prefix for graphile-worker queue job names. Useful when sharing a database betwe
160
160
 
161
161
  Number of concurrent workers polling for jobs. Default: `10`
162
162
 
163
+ ### `WORKFLOW_POSTGRES_MAX_POOL_SIZE`
164
+
165
+ Maximum size of the internal `pg.Pool` used when `createWorld()` constructs the pool. Default: `10`
166
+
167
+ For higher worker concurrency, Graphile Worker recommends setting `maxPoolSize` to `10` or `queueConcurrency + 2`, whichever is larger.
168
+
163
169
  ### Programmatic configuration
164
170
 
165
171
  {/* @skip-typecheck: incomplete code sample */}
@@ -170,6 +176,7 @@ const world = createWorld({
170
176
  connectionString: "postgres://user:password@host:5432/database",
171
177
  jobPrefix: "myapp_",
172
178
  queueConcurrency: 20,
179
+ maxPoolSize: 20, // overrides WORKFLOW_POSTGRES_MAX_POOL_SIZE
173
180
  });
174
181
  ```
175
182
 
@@ -85,7 +85,7 @@ Unit testing works well for individual steps. A simple workflow that only calls
85
85
  For workflows that rely on runtime features like [hooks](/docs/foundations/hooks), [webhooks](/docs/foundations/hooks#understanding-webhooks), [`sleep()`](/docs/api-reference/workflow/sleep), or error retries, you need to test against a real workflow setup. The `@workflow/vitest` plugin handles everything automatically — it compiles your workflow directives, builds the runtime bundles, and executes workflows entirely in-process. No server required.
86
86
 
87
87
  <Callout type="warn">
88
- Inside integration tests, which run the full workflow runtime, `vi.mock()` and related calls do not work neither for your own modules nor for third-party npm packages. All step dependencies are inlined into the compiled bundle by esbuild, bypassing Vitest's module system entirely. To test steps with mocked dependencies, use [unit tests](#unit-testing-steps) instead. Consider dependency injection or environment variable-based conditional logic for controlling behavior in integration tests.
88
+ `vi.mock()` and related calls do _not_ work inside workflow functions, only step functions. Your workflow functions cannot import third party code that needs to be mocked. Mocking works for npm packages imported in step functions. If something needs to be mocked, it likely belongs inside a step function either way.
89
89
  </Callout>
90
90
 
91
91
  ### Vitest Configuration
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "workflow",
3
- "version": "4.2.0-beta.72",
3
+ "version": "4.2.0-beta.73",
4
4
  "description": "Workflow DevKit - Build durable, resilient, and observable workflows",
5
5
  "main": "dist/typescript-plugin.cjs",
6
6
  "type": "module",
@@ -57,18 +57,18 @@
57
57
  },
58
58
  "dependencies": {
59
59
  "ms": "2.1.3",
60
- "@workflow/astro": "4.0.0-beta.46",
61
- "@workflow/cli": "4.2.0-beta.72",
62
- "@workflow/core": "4.2.0-beta.72",
60
+ "@workflow/astro": "4.0.0-beta.47",
61
+ "@workflow/cli": "4.2.0-beta.73",
62
+ "@workflow/core": "4.2.0-beta.73",
63
63
  "@workflow/errors": "4.1.0-beta.19",
64
64
  "@workflow/typescript-plugin": "4.0.1-beta.5",
65
65
  "@workflow/utils": "4.1.0-beta.13",
66
- "@workflow/next": "4.0.1-beta.68",
67
- "@workflow/nest": "0.0.0-beta.21",
68
- "@workflow/nitro": "4.0.1-beta.67",
69
- "@workflow/nuxt": "4.0.1-beta.56",
70
- "@workflow/sveltekit": "4.0.0-beta.61",
71
- "@workflow/rollup": "4.0.0-beta.29"
66
+ "@workflow/next": "4.0.1-beta.69",
67
+ "@workflow/nest": "0.0.0-beta.22",
68
+ "@workflow/nitro": "4.0.1-beta.68",
69
+ "@workflow/nuxt": "4.0.1-beta.57",
70
+ "@workflow/sveltekit": "4.0.0-beta.62",
71
+ "@workflow/rollup": "4.0.0-beta.30"
72
72
  },
73
73
  "devDependencies": {
74
74
  "@types/ms": "2.1.0",