Skip to content

Let business code use the temporalx event helpers #106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
duynhne merged 1 commit into from
Sep 24, 2026
Merged

Let business code use the temporalx event helpers #106

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,7 +85,7 @@ Today no module imports another at all; the layers say what is *allowed* if one
Concrete rules that follow from this:

- **OpenTelemetry API vs SDK.** `logger/*`, `grpcx`, and `dbx` may import `go.opentelemetry.io/otel` (the API), `otel/trace`, `otel/metric`, and contrib instrumentation (`otelgrpc`, `otelpgx`). They must **never** import `go.opentelemetry.io/otel/sdk` or `duynhlab/pkg/obsx`. The SDK lives in `obsx` and nowhere else. This is what lets a service use `grpcx` without being forced to link the OpenTelemetry SDK. (Tests are exempt: in-memory exporters need the SDK.)
- **`obsx`, `temporalx`, and `migratex` are wired in `main()` only.** Service business packages must not import them. `dbx` is exempt from this rule — repository/store code may use it — but no module *in this repo* may.
- **`obsx`, `temporalx`, and `migratex` are wired in `main()` only.** Service business packages must not import them, with one narrow exception: temporalx's workflow-side helpers — `Tracer` for replay-safe spans, `WorkflowEvent`, and `WorkflowFailed` — are for workflow, activity and dispatcher code, because the event catalog assigns those events to temporalx and only it may write from workflow code. Construction (`Dial`, `NewWorker`, `WithLogger`) stays in `main()`. `dbx` is exempt from this rule — repository/store code may use it — but no module *in this repo* may.
- **`migratex` does not import `dbx`.** It accepts a DSN string. Keeping them independent means a migration job binary does not link the pool implementation and vice versa.
- **`grpcx` does not import `proto`.** Interceptors are generic. Anything that needs a concrete message type belongs in the service.
- **`httpx` and `authmw` do not import each other.** Both produce gin middleware/helpers. Composition happens in the service.
Expand Down
Loading