Update deps #3064
Update deps #3064
Conversation
Mostly fixes for zstd
Seems like the usual amount of random updates for syscalls, bugfixes and security issues. The only interesting thing is a fix for http2 connections, where a failed request will mark the connection as not reusable. Which might reduce the amount of strange errors (EOF) in some cases, maybe.
|
grpc is not updated as there are problems - issue pending |
Codecov Report
@@ Coverage Diff @@
## master #3064 +/- ##
==========================================
- Coverage 76.72% 76.71% -0.01%
==========================================
Files 229 229
Lines 17110 17110
==========================================
- Hits 13127 13126 -1
Misses 3140 3140
- Partials 843 844 +1
Flags with carried forward coverage won't be shown. Click here to find out more. |
| func init() { | ||
| // Opt-in for ansi color support for current process. | ||
| // https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#output-sequences | ||
| var outMode uint32 | ||
| out := windows.Handle(os.Stdout.Fd()) | ||
| if err := windows.GetConsoleMode(out, &outMode); err != nil { | ||
| return | ||
| } | ||
| outMode |= windows.ENABLE_PROCESSED_OUTPUT | windows.ENABLE_VIRTUAL_TERMINAL_PROCESSING | ||
| _ = windows.SetConsoleMode(out, outMode) |
There was a problem hiding this comment.
According to that MS link, this does much more than add color support to Windows terminals. And I think we already supported color on Windows, no? There was some wonky behavior, mainly with Unicode characters, but color was never an issue, AFAIR.
Even if this seems like a safe change, we should still test the behavior on Windows to ensure our UI hacks continue to work.
There was a problem hiding this comment.
Even if this seems like a safe change, we should still test the behavior on Windows to ensure our UI hacks continue to work.
I did test both powershell and cmd and it looks exactly the same as before 🤷 .
cmd still does not show unicode and powershell seems as okay as I can expect.
The only discrepancy is that with both old and new version hitting enter while a test is running - does nothing :(.
But that seems like completely unrelated issue and also not really a problem as we do not care about anytnig but ^C 🤞
There was a problem hiding this comment.
From fatih/color#169 (comment) - it is apparently about other terminals that do the more ... accurate handling of colors - where they are not supported unless the application tells them they want them. Which apparently is what this code does.
I unfortunately do not have a terminal that has his problem :(.
| ## Catastrophic Backtracking and Timeouts | ||
|
|
||
| `regexp2` supports features that can lead to catastrophic backtracking. | ||
| `Regexp.MatchTimeout` can be set to to limit the impact of such behavior; the | ||
| match will fail with an error after approximately MatchTimeout. No timeout | ||
| checks are done by default. | ||
|
|
||
| Timeout checking is not free. The current timeout checking implementation starts | ||
| a background worker that updates a clock value approximately once every 100 | ||
| milliseconds. The matching code compares this value against the precomputed | ||
| deadline for the match. The performance impact is as follows. |
There was a problem hiding this comment.
This is an indirect dependency used by goja, and MatchTimeout is not used there yet. I guess this is up to Dmitry to decide whether it makes sense, but it could have an impact for us if he decides to enable it.
There was a problem hiding this comment.
Yes - it is, but goja does not update it as regularly as I would prefer and we already have updated in the past to get some unlikely fixes.
This current update does not matter to use but removes the need to review this change in the future.
| if cs.ID != 0 { | ||
| // This request may have failed because of a problem with the connection, | ||
| // or for some unrelated reason. (For example, the user might have canceled | ||
| // the request without waiting for a response.) Mark the connection as | ||
| // not reusable, since trying to reuse a dead connection is worse than | ||
| // unnecessarily creating a new one. | ||
| // | ||
| // If cs.ID is 0, then the request was never allocated a stream ID and | ||
| // whatever went wrong was unrelated to the connection. We might have | ||
| // timed out waiting for a stream slot when StrictMaxConcurrentStreams | ||
| // is set, for example, in which case retrying on a different connection | ||
| // will not help. | ||
| cs.cc.doNotReuse = true |
There was a problem hiding this comment.
This seems like a good thing, and probably safe for us(?) 🤞
There was a problem hiding this comment.
I am hopeful that this will fix some EOF errors for some users. Also this is very likely to already have landed in stdlib as it is just x/net vendored.
| github.com/go-sourcemap/sourcemap v2.1.4-0.20211119122758-180fcef48034+incompatible | ||
| github.com/golang/protobuf v1.5.2 | ||
| github.com/gorilla/websocket v1.5.0 | ||
| github.com/grafana/xk6-browser v0.9.0 | ||
| github.com/grafana/xk6-output-prometheus-remote v0.1.0 | ||
| github.com/grafana/xk6-output-prometheus-remote v0.2.0 |
There was a problem hiding this comment.
No description provided.