## What changed?
- Reduced log level of failed Nexus requests originating from worker to
debug level.
- Updated CONTRIBUTING.md and testing.md to reflect current status and
to include IDE debugging.
- Added failure source setting to worker in nexus handler when dispatch
context deadline exceeded.
## Why?
- Today we log an error for every request, which pollutes server logs
and is inconsistent with activity and workflow task failures. We don't
want to completely lose visibility into these errors since some of the
errors can originate internally and may be tricky to debug.
- We've missed spots in setting worker failure source in the nexus
handler
- The docs are a bit outdated, and it's also helpful to have IDE
specific debugging instructions.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Ticket
[OSS-4548](https://temporalio.atlassian.net/browse/OSS-4548)
[OSS-4548]:
https://temporalio.atlassian.net/browse/OSS-4548?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
---------
Co-authored-by: Roey Berman <[email protected]>
## What changed?
<!-- Describe what has changed in this PR -->
Increased OTEL_BSP_SCHEDULE_DELAY from 0 to 100ms.
## Why?
<!-- Tell your future self why have you made these changes -->
Zero is too aggressive and leads to too much CPU usage.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Fixed code coverage reporting.
## Why?
<!-- Tell your future self why have you made these changes -->
We haven't reported code coverage in over a year.
It stopped working when we moved away from Buildkite.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Checkout https://app.codecov.io/gh/temporalio/temporal
There's no data for main ("master") yet, though, until we merge.
I'll also leave the README coveralls badge there for now.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Remove `key` parameter from `testvar` methods.
## Why?
<!-- Tell your future self why have you made these changes -->
It turn out to be confusing for people on how to use optional `key`
parameter. @bergundy got a great idea to remove this parameter and use
different instance of `tv` when more than one entity is needed.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Run all tests. Refactoring affects test code only.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
Yes, updated testing docs.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.
## What changed?
<!-- Describe what has changed in this PR -->
Added new taskpoller to project's testing guidelines.
## Why?
<!-- Tell your future self why have you made these changes -->
To recommend this behavior to newcomers.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Added Grafana Tempo - an OTEL collector - to the developer setup.
Since we're already using Grafana, Tempo seemed like a logical choice.
## Why?
<!-- Tell your future self why have you made these changes -->
It allows developers to see all the RPC calls they are making (e.g. when
running the server locally or a functional test).
Tempo allows filtering by workflow ID. _(note that not _all_ places are
tagged yet, but lots of them)_
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
```
make start-grafana-tempo
make OTEL=true start
```
```
tctl --ns default namespace register
tctl wf start --tq test --wid test -wt test
```
<img width="3352" alt="image"
src="https://github.com/user-attachments/assets/5809691a-da32-4a04-8e80-700f8acd47e5"
/>
And running a functional test from the IDE:
<img width="3346" alt="image"
src="https://github.com/user-attachments/assets/061bfaf3-0a34-4b4e-a06c-497dfa3a948a"
/>
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
Updated docs/development/tracing.md
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
- Remove `proto/api` submodule.
- Adds a new program that's automatically run by the Makefile as
required to output the api protos in binary form, which can be used by
most tools. The command is run by `go run` and uses the same api-go
reference as the rest of the server for the source protos.
- Removed http annotations from internal matchingservice proto.
## Why?
- Ensure that the api-go import (in go.mod) and the proto files imported
by this repo's proto files are always in sync.
- Simplify update process, stop having to mess with submodules.
## How did you test it?
running commands manually a lot
## Potential risks
Importing protos from somewhere other than our api and google well-known
protos may require some updates to the script's import path logic.
## Documentation
updated docs
## What changed?
<!-- Describe what has changed in this PR -->
Create new `testing.md` with test-specific developer guidance.
It's still very short, happy to add anything else now if there is any -
or just grow it over time.
## Why?
<!-- Tell your future self why have you made these changes -->
To document testing patterns and agreements.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
I reorganized our docs into `docs/{admin,architecture,development}`.
## Why?
<!-- Tell your future self why have you made these changes -->
We discussed this internally, but I believe this is a better
segmentation for the different audiences looking at our docs. I plan on
adding more stuff to docs/admin like metrics and dynamic config docs.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
I'm mainly looking for broken links.
- I went through each markdown file in docs manually.
- I looked through all inspection errors in the IDE.
- I looked at all references to "docs/" or "develop/" in our code.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
