Agent event creation timestamps #886
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR addresses an issue with agent event timestamps by capturing the actual event creation time rather than when events are processed, ensuring accurate and non-identical timestamps.
- Updated the hostPublishEvent API signatures in Go and AssemblyScript with an additional createdAt parameter.
- Modified event publishing functions to generate and pass a createdAt timestamp.
- Updated runtime functions to parse and propagate the createdAt timestamp.
Reviewed Changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| sdk/go/pkg/agents/imports_wasi.go | Updated hostPublishEvent signature with createdAt parameter |
| sdk/go/pkg/agents/imports_mock.go | Updated hostPublishEvent signature and call with createdAt parameter |
| sdk/go/pkg/agents/agents.go | Captures the createdAt timestamp and passes it to hostPublishEvent |
| sdk/assemblyscript/src/assembly/agent.ts | Added createdAt timestamp and updated call to hostPublishEvent |
| sdk/assemblyscript/src/assembly/tests/agent.spec.ts | Updated test mocks for hostPublishEvent signature with createdAt |
| runtime/hostfunctions/agents.go | Modified host function registration to accept createdAt |
| runtime/actors/agents.go | Updated PublishAgentEvent to parse and use createdAt as the event time |
Comments suppressed due to low confidence (1)
runtime/hostfunctions/agents.go:50
- The detail message currently only includes agentId and eventName. Consider including the createdAt timestamp in the returned message to enhance observability and debugging.
withMessageDetail(func(agentId, eventName string, eventData *string, createdAt *string) string {
| event := &messages.AgentEventMessage{ | ||
| Name: eventName, | ||
| Data: dataValue, | ||
| Timestamp: timestamppb.Now(), |
There was a problem hiding this comment.
The problem stems from this Timestamp: timestamppb.Now() - its the published to network time, not the event captured time.
There was a problem hiding this comment.
There should be almost zero delay between capture and publish though. There's no queue involved at that level. It's just a wasm guest to host function call.
|
Thanks for the clarity, Matt. I managed to fix my issue on my end, closing this. |
2 participants
Events published by agents were showing identical timestamps even when there was significant time between them (e.g., a "generating" event followed by a "generated" event after an LLM call). This PR captures timestamps when agents actually create events rather than when the runtime processes them, ensuring unique and accurate timing information.