Skip to content

Conversation

@fhanau
Copy link
Contributor

@fhanau fhanau commented Oct 2, 2025

Also see the downstream PR.

@mar-cf I'm not sure if this is actually an improvement (the workerd version becomes more convoluted), Kenton suggested this change as the current approach violates KJ style

@fhanau fhanau requested a review from mar-cf October 2, 2025 23:19
@fhanau fhanau requested review from a team as code owners October 2, 2025 23:19
}

// Initialize streaming tail worker.
// TODO(streaming-tail): memory management is off here – we need to add this to the pipeline
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This thing is not great – note that it is not newly added in this PR, but just ported from downstream. Last time I tested removing this it seemed to not break tests, I can try removing it in a future PR.

@mar-cf
Copy link
Contributor

mar-cf commented Oct 13, 2025

@kentonv could you clarify your suggestion to PipelineTracer? Is it in your opinion that it's cleaner if we move all we can into workerd? How should we handle internal repo specific behavior? Is there some prior art we could follow?

@kentonv
Copy link
Member

kentonv commented Oct 17, 2025

@mar-cf

Is it in your opinion that it's cleaner if we move all we can into workerd?

No, my suggestion was the opposite: Move PipelineTracer into the internal codebase.

It is not meaningfully referenced anywhere in workerd. The only trick is that WorkerTracer contains kj::Maybe<kj::Rc<PipelineTracer>> parentPipeline;, but this is just an opaque reference that is held only to keep the object alive, so it could be changed to kj::Maybe<kj::Own<void>> instead.

@fhanau
Copy link
Contributor Author

fhanau commented Oct 18, 2025

No, my suggestion was the opposite: Move PipelineTracer into the internal codebase.

It is not meaningfully referenced anywhere in workerd. The only trick is that WorkerTracer contains kj::Maybe<kj::Rc<PipelineTracer>> parentPipeline;, but this is just an opaque reference that is held only to keep the object alive, so it could be changed to kj::Maybe<kj::Own<void>> instead.

This no longer applies now that workerd supports tail workers: If tracing is set up, server/server.c++ creates a PipelineTracer and uses it to set up WorkerTracers and the streaming/legacy tail workers that have been configured. It might be possible to refactor the implementation to go without PipelineTracer, but getting memory management right and replacing the behavior of onComplete() would make this a more difficult task.

@mar-cf
Copy link
Contributor

mar-cf commented Oct 28, 2025

This might benefit from a quick sync to align on the goal and cover some implementation obstacles. We can progress faster, or decide it's more hassle than worth, if we're on the same page.

@fhanau
Copy link
Contributor Author

fhanau commented Nov 13, 2025

Superseded by #5519.

@fhanau fhanau closed this Nov 13, 2025
@fhanau fhanau deleted the felix/100225-SPT-consolidate branch November 13, 2025 02:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants