## What changed?
- Add counter metric for total suspected deadlocks
- Add gauge metric for current unresolved suspected deadlocks
## Why?
These could be used in alerting or health checking.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
<!-- Describe what has changed in this PR -->
Remove license header from every file. Because it is really hard to
follow in this PR here is the summary:
1. License header is removed from all `.go` and `.proto` files
:fireworks::fireworks:🎆.
2. `LICENSE` file in the root directory has only Temporal and Uber
copyrights.
3. 5 other `LICENSE` files added to the packages which have copyrights
different from Temporal and Uber: Datadog, Xargin, "Mat Ryer, Tyler
Bunnell and contributors".
4. `license_file` flag is removed from all code generation tools.
5. `copyright_file` flag is removed from `go:generate mockgen`
directive.
6. All copyright related targets are removed from `Makefile`.
7. Updated Temporal copyright year to 2025 everywhere.
## Why?
<!-- Tell your future self why have you made these changes -->
I double checked with legal department that it is not needed to have
license header in every file. One file per repo is enough. I put all
copyrights to the root `LICENSE` file and removed header from all other
files. Also updated tools and `Makefile`.
## What changed?
<!-- Describe what has changed in this PR -->
Moved all packages inside `/internal` to `/common`.
## Why?
<!-- Tell your future self why have you made these changes -->
While the `internal` package provides the benefit of preventing any
external party from depending on them, we find that in practice this has
little benefit.
Our compatibility guarantees do not coverage any APIs in `common`
anyway.
Furthermore, splitting commonly-used packages into two places hinders
discoverability. And adds (albeit minor) mental friction.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Compiler.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
External users could start relying on these packages. But that's their
risk assessment to make. There are no guarantees (just like for any
other package in this repo!) outside of the external APIs.
## 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?
Make import formatting a part of the build, and test validity with
"ensure-no-changes" target
## Why?
So we never discuss import order again (hopefully)
## How did you test it?
its a build change, so the build will test it!
## Potential risks
As long as build works, the only thing I risk is the ire of coworker who
want imports to be different ;)
## Documentation
N/A
## Is hotfix candidate?
No
## What changed?
- Run checks every 60s instead of 30s.
- Increase grace period for shard lock and shard io semaphore checks.
## Why?
These are a little too sensitive and can fire when persistence is slow
for an extended time. The longer timeouts will still catch true
deadlocks in a reasonable amount of time.
## How did you test it?
didn't
## What changed?
Dynamic config improvements:
- Typed settings to prevent misuse
- Moved defaults to where settings are defined
- Code generation to make it easy to add new types and filters
- Shorter names for readability
## Why?
Making it easier to use, preventing misuse, making it easy to extend,
easier to parse and generate documentation from, base for future
enhancements (e.g. validation at load time)
## How did you test it?
modified existing tests
## Potential risks
typo or missed something in all the merges and refactors
<!-- Describe what has changed in this PR -->
**What changed?**
I replaced all usages of `time.After` with `time.NewTimer`. I also added
a linter rule which bans usage of `time.After`.
<!-- Tell your future self why have you made these changes -->
**Why?**
`time.After` leaks resources. It's unclear what resources exactly
because `startTimer` is [implemented in
src/runtime](https://go.dev/src/runtime/time.go#L206), and the docs just
say "The underlying Timer is not recovered by the garbage collector
until the timer fires."
In any case, `NewTimer` is strictly more efficient, and it's not much
harder to use.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
I verified that I can create an issue with it:
<img width="1415" alt="image"
src="https://github.com/temporalio/temporal/assets/5942963/315b6839-bdd4-4127-a3dc-1db966755366">
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
This is a bit more verbose for people to use. People also may forget to
call `.Stop()`.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No
