Commit Graph

8 Commits

Author SHA1 Message Date
ThinkChaos b335887992 refactor(log): store log in context so it's automatically propagated 2024-03-19 19:10:07 -04:00
ThinkChaos dd76cf5bb0 fix: add `Resolver.String` so logs don't use Go's default format 2024-01-18 10:47:04 -05:00
ThinkChaos a6654dcd57 refactor(config): rename `StartStrategyType` to `InitStrategy` 2023-12-05 20:52:46 -05:00
ThinkChaos 7a3c054b43 feat: add `upstreams.init.strategy`
Replaces `startVerifyUpstream` and behaves just like
`blocking.loading.strategy`.

We use the bootstrap resolver for any requests that arrive before the
upstreams are initialized.
2023-12-05 20:52:46 -05:00
ThinkChaos b386e22ebe refactor: embed `Upstreams` in `UpstreamGroup` to make values accessible
Move `startVerifyUpstream` to `upstreams.startVerify` so it's accessible
via `UpstreamGroup` and we don't need to pass `startVerify` to all
resolver constructors that call `NewUpstreamResolver`.

Also has the nice benefit of greatly reducing the usage of `GetConfig`.
2023-11-23 08:45:18 -05:00
ThinkChaos eae99ec550 refactor: make use of contexts in more places
- `CacheControl.FlushCaches`
- `Querier.Query`
- `Resolver.Resolve`

Besides all the API churn, this leads to `ParallelBestResolver`,
`StrictResolver` and `UpstreamResolver` simplification: timeouts only
need to be setup in one place, `UpstreamResolver`.

We also benefit from using HTTP request contexts, so if the client
closes the connection we stop processing on our side.
2023-11-21 12:21:35 -05:00
DerRockWolf 94663eeaeb
feat: add upstream strategy `random` (#1221)
Also simplify code by getting rid of `resolversPerClient` and all surrounding logic.
2023-11-18 15:42:14 -05:00
DerRockWolf c112e86740
feat: add upstream strategy `strict` (#1093) 2023-08-21 09:50:23 +02:00