zuplo 7.11.6 → 7.11.8

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.
@@ -25,6 +25,30 @@ search, and filters for severity, status, method, and route. Live mode streams
25
25
  new entries as they arrive and pauses automatically, for example when you select
26
26
  a request to inspect it.
27
27
 
28
+ Each request row shows the path the client called, such as `/users/42`. Hover
29
+ the path to see the full URL and the route it matched, such as `/users/:id`.
30
+ Select a request to open its details, which list:
31
+
32
+ - **URL**: the full URL of the request, including the query string.
33
+ - **Route Path**: the route in your OpenAPI file that handled the request.
34
+ - **Properties**: any [custom log properties](#custom-log-properties) your code
35
+ set for the request.
36
+
37
+ When your code calls another route with
38
+ [`context.invokeRoute`](../programmable-api/zuplo-context.mdx#invokeroute), the
39
+ called route gets a log row of its own with the same request ID. The viewer
40
+ nests that row under the request that made the call and marks it **Subrequest**,
41
+ so a request and its sub-requests read as one group even when their status codes
42
+ differ.
43
+
44
+ :::caution
45
+
46
+ The log viewer shows the full URL of each request, including its query string.
47
+ Don't pass secrets such as API keys or tokens as query parameters; send them in
48
+ headers instead.
49
+
50
+ :::
51
+
28
52
  Logs are also available at the account scope, so you can debug across every
29
53
  project in an account in one place. Open
30
54
  [**Observability → Logs**](https://portal.zuplo.com/+/account/observability/logs)
@@ -112,8 +136,10 @@ details.
112
136
 
113
137
  ## Custom Log Properties
114
138
 
115
- In addition to the default fields, you can also add custom fields to your logs.
116
- This can be done using the `context.log.setLogProperties!` method.
139
+ In addition to the default fields, you can add custom properties to a request
140
+ with the `context.log.setLogProperties!` method. Use them for values you want to
141
+ see on the request, such as a tenant ID, a feature flag, or an experiment
142
+ variant.
117
143
 
118
144
  ```ts
119
145
  import { ZuploContext, ZuploRequest } from "@zuplo/runtime";
@@ -122,18 +148,52 @@ export default async function policy(
122
148
  request: ZuploRequest,
123
149
  context: ZuploContext,
124
150
  ) {
125
- context.log.setLogProperties!({ customProperty: "value" });
151
+ context.log.setLogProperties!({
152
+ tenantId: "acme",
153
+ pricingExperiment: "variant-b",
154
+ cached: false,
155
+ });
126
156
  context.log.info("Hello World");
127
157
  return request;
128
158
  }
129
159
  ```
130
160
 
131
- These properties will be included in all subsequent log messages for that
132
- request. If the property already exists, it will be overwritten.
133
-
134
- The log properties will be exported in a format native to the plugin you are
135
- using. For example, in the case of the OpenTelemetry plugin, the properties will
136
- be included in the `attributes` field of the log record.
161
+ Custom log properties show up in two places:
162
+
163
+ - **Your logging plugins**: every log message for the request logged after the
164
+ call includes the properties. They're exported in a format native to the
165
+ plugin you use. For example, the OpenTelemetry plugin includes them in the
166
+ `attributes` field of the log record.
167
+ - **The log viewer in the Zuplo Portal**: the request's details list the
168
+ properties in the **Properties** section. See
169
+ [Viewing logs in the portal](#viewing-logs-in-the-portal).
170
+
171
+ Custom log properties work as follows:
172
+
173
+ - Properties apply only to the request that sets them.
174
+ - Values can be strings, numbers, or booleans.
175
+ - Each call merges into the properties already set for the request. If a
176
+ property already exists, it's overwritten.
177
+ - A per-request property overrides a static field with the same name from your
178
+ logging plugin's `fields` option, for plugins that have one.
179
+ - A route called with
180
+ [`context.invokeRoute`](../programmable-api/zuplo-context.mdx#invokeroute)
181
+ starts with no custom log properties of its own, and its properties appear on
182
+ its own row in the log viewer, not on the calling request.
183
+
184
+ To keep requests small in the log viewer, the following limits apply there. A
185
+ property that breaks a limit is left out of the log viewer, or, for a value
186
+ that's too long, truncated. Log messages sent to your logging plugins aren't
187
+ limited this way.
188
+
189
+ | Limit | Value |
190
+ | ---------------------- | ---------------- |
191
+ | Properties per request | 64 |
192
+ | Key length | 128 characters |
193
+ | Value length | 2,048 characters |
194
+
195
+ The `!` in `setLogProperties!` is a TypeScript non-null assertion: the method is
196
+ typed as optional on the logger, but it's always available on `context.log`.
137
197
 
138
198
  ## Performance Under High Load
139
199
 
@@ -115,6 +115,11 @@ context.log.warn(["a", "warning"]);
115
115
  context.log.error({ Oh: "my!" });
116
116
  ```
117
117
 
118
+ To add properties to the request, use `context.log.setLogProperties`. They're
119
+ included in every later log message for the request and shown in the request's
120
+ details in the log viewer. See
121
+ [Custom Log Properties](../articles/logging.mdx#custom-log-properties).
122
+
118
123
  ### `parentContext`
119
124
 
120
125
  Reference to the parent context when using `invokeRoute`. This property is
@@ -270,6 +275,10 @@ Invokes another route within the same Zuplo Gateway. This enables internal
270
275
  routing and composition of multiple routes. The invoked route runs with a new
271
276
  context that has `parentContext` set to the current context.
272
277
 
278
+ The invoked route is logged as a sub-request: it gets a log row of its own with
279
+ the same request ID, and the log viewer nests it under the calling request. See
280
+ [Viewing logs in the portal](../articles/logging.mdx#viewing-logs-in-the-portal).
281
+
273
282
  ```ts
274
283
  export default async function (request: ZuploRequest, context: ZuploContext) {
275
284
  // First, validate the request using an internal route
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "zuplo",
3
- "version": "7.11.6",
3
+ "version": "7.11.8",
4
4
  "type": "module",
5
5
  "description": "The official Zuplo CLI for local development and platform management",
6
6
  "homepage": "https://zuplo.com/docs/cli/overview",
@@ -32,9 +32,9 @@
32
32
  "zuplo": "zuplo.js"
33
33
  },
34
34
  "dependencies": {
35
- "@zuplo/cli": "7.11.6",
36
- "@zuplo/core": "7.11.6",
37
- "@zuplo/runtime": "7.11.6",
38
- "@zuplo/test": "7.11.6"
35
+ "@zuplo/cli": "7.11.8",
36
+ "@zuplo/core": "7.11.8",
37
+ "@zuplo/runtime": "7.11.8",
38
+ "@zuplo/test": "7.11.8"
39
39
  }
40
40
  }