OpenFn / OpenFn/kit

worker: prefix run id to all logs for that run

Open
#1,098 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

DevX
Dominant language
TypeScript
Stars
21
Forks
23
Avg merge
1d 22h
Merged PRs (30d)
17

Description

When a run logs to GCP, it can be hard to know which run it logs to. You get output like this:

[R/T] ❯ Starting operation 1

Which isn't helpful.

What I'd really like is to automatically prefix the run to the log line somehow, so I can differentiate.

The dumb obvious way is:

[R/T] ❯ [ef8acfe6-943d-4b2f-9bff-739e70e6b9eb] Starting operation 1

A smarter way to do this might be by adding some kind of metadata label for GCP, a la #1043. That would be visually tidier I think?

Either way I think we need support for this in the Logger itself, some kind of prefix. Not the namespace, but something to go along side it. Then each Run needs its own private logger instance.

Note that these are system logs produced by the runtime and engine itself - not logs within the sandbox. Those are private.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the worker's Run and Logger entry points and tracing how system logs are emitted to GCP. Compare a logger prefix with GCP metadata labels, then define the chosen run-identification behavior and verify that logs from separate runs remain distinguishable without changing sandbox logs.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
observability
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.