`void/log`: add `logger.child(fields)` to bind fields to every line
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 82/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend
Línea de trabajo
Start with void/src/runtime/log.ts and the existing format() try block to see how fields are copied and filtered. Then read test/unit/runtime-log.test.ts and add coverage for bound fields, overrides, nested children, and throwing getters; update the Logging methods line in docs/reference/api/resources.md with a one-line example. Done when the requested behaviors pass and logging still returns the safe line for throwing getters.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
Apps usually tag every log line from a module with the same fields (component, queue, job), so the lines can be filtered in Workers Logs and with void project logs --filter. void/log has no way to bind those fields, so each call repeats them, or each app writes its own wrapper. The obvious wrapper breaks the logger's guarantee that it never throws.
The wrapper apps write today
import { logger as baseLogger } from 'void/log';
type Fields = Record<string, unknown>;
export const logger = {
...baseLogger,
child: (bound: Fields) => ({
error: (msg: string, fields?: Fields) => baseLogger.error(msg, { ...bound, ...fields }),
warn: (msg: string, fields?: Fields) => baseLogger.warn(msg, { ...bound, ...fields }),
info: (msg: string, fields?: Fields) => baseLogger.info(msg, { ...bound, ...fields }),
}),
};
The spread { ...bound, ...fields } runs before format(). That means it runs outside the try that makes logging safe. A field whose getter throws makes the base logger fall back to its safe line, but the wrapper throws the error into the caller instead ([email protected]; format() on main has the same try):
const fields = Object.defineProperty({}, 'boom', {
enumerable: true,
get() {
throw new Error('getter');
},
});
logger.info('base.ok', fields);
// {"msg":"base.ok","error":"log: fields not serializable"}
logger.child({ component: 'x' }).info('child.call', fields);
// throws Error: getter
A log call inside a catch or a queue consumer can then throw where it was meant to only record. Supporting this in void/log means each app no longer copies the wrapper, and the merge stays inside the guarantee.
Proposal
import { logger } from 'void/log';
const log = logger.child({ component: 'queue', queue: 'tasks' });
log.warn('task.retry', { taskId, attempt: 2 });
// {"msg":"task.retry","component":"queue","queue":"tasks","taskId":"…","attempt":2}
logger.child(fields)returns a logger witherror,warn,infoandchild.- Lines keep the
{ msg, ...fields }shape, so Cloudflare Tail capture and platform log filtering don't change. - Fields passed in a call override bound fields with the same name.
child()can be nested:log.child({ taskId })adds to the fields already bound.- Bound fields get the same handling as call fields.
msg,toJSON,__proto__andconstructorare skipped, functions are dropped, andErrorvalues are serialized (#583). - Logging never throws, including when bound or call fields have throwing getters.
Implementation
In packages/void/src/runtime/log.ts, build each logger from a bound object and have format(message, bound, fields) copy both inside the existing try. Bound fields are copied first, then call fields, using the same key filters. logger stays the root, with no bound fields, so existing calls behave the same.
Tests in packages/void/test/unit/runtime-log.test.ts:
- bound fields appear on every level
- call fields override bound fields
- nested
child()merges fields - reserved keys and functions in bound fields are skipped
- a throwing getter in bound or call fields falls back to the safe line instead of throwing
Docs: add logger.child(fields) to the methods line under Logging in docs/reference/api/resources.md, with a one-line example.
I'm happy to send the PR.
- Lenguaje dominante
- TypeScript
- Estrellas
- 580
- Forks
- 56
- Merge medio
- 12 h 25 min
- PR fusionados (30 d)
- 134
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de voidzero-dev/void
-
Dificultad 3/5 1-2 días Aptitud para principiantes 66/100
voidzero-dev/void#599 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 56/100
voidzero-dev/void#579 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
voidzero-dev/void#575 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
voidzero-dev/void#573 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 53/100
voidzero-dev/void#567 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de voidzero-dev/void
Issues similares
-
e2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
redhat-developer/rhdh-plugin-export-overlays#4580 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
devdotfast/whiteboard#1415 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area/sessions comp/desktop desktop/sessions P2 type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
NousResearch/hermes-agent#145383 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
enhancement p2 setup
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
vercel/eve#5419 · 1 comentario ·
Los mantenedores suelen responder en 1 día