Update WebFlux integration to leverage Brave's NettyHttpTracing

Is your feature request related to a problem? Please describe.
I'm trying to leverage Logbook with Spring's WebFlux and Reactor implementation and Sleuth but the span and trace ids from Sleuth are not available to Logbook at the time it's logging the request. Logbook adds itself as a Netty handler, which I think is a smart way to do this as it's outside of all other processing. The main issue I see is when Logbook logs the incoming request it is way before Sleuth has done anything with span or trace ids and thus it does not include them in its log. The response log does properly include them as it executes after the Sleuth logic.
Describe the solution you'd like
I see that Brave has built it's own Netty handler and I would like Sleuth to leverage this and connect the Netty layer into the Reactor context so it will continue to propagate the ids.
Describe alternatives you've considered
I considered just checking for B3 headers myself in the Netty layer and if missing generating them right then and adding them to the request before it continues. I figured this would work as Sleuth would see this as span and trace ids already existing and use them. I wasn't able to get this working easily and I wasn't even sure if it would work as it might generate a new span id if it thinks it's a request from another service.

Do you have a sample that I could play with to check this instrumentation?

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@marcingrzejszczak I've created a simple example app here (https://github.com/btkelly/Sleuth-Netty-Example) let me know if you need anything else added to test. Thanks for looking into this!

So @violetagg is working on fixing this in reactor netty.

@btkelly @marcingrzejszczak Can you take a look at https://github.com/reactor/reactor-netty/pull/1307

@violetagg It looks good and I was attempting to test it but was having trouble getting the pre release version of Reactor to sync with Gradle using the Spring dependency plugin. Have these changes been released in any of the snapshot repos or do I need to pull them down from source? Any help would be appreciated.

@btkelly yes use https://repo.spring.io/snapshot/ and for reactor bom use 2020.0.0-SNAPSHOT

Alright I was able to pull in the changes and test in my sample app and am still seeing the same issue but I might be configuring Netty incorrectly. Included below is how I'm configuring the newly added BraveHttpServerTracing along with the LogbookServerHandler which results in the same behavior of Logbook's logging occuring without Sleuth ids being present in the logs as shown below.
Log Output:
2020-09-30 13:11:05.281 TRACE [SleuthNettyExample,,] 36549 --- [ctor-http-nio-3] org.zalando.logbook.Logbook              : Incoming Request: 9e3c787dfc9db85c
Netty Configuration:
    @Bean
    fun braveHttpServerTracing(httpTracing: HttpTracing) = BraveHttpServerTracing
        .create(httpTracing) as BraveHttpServerTracing

    @Bean
    @ConditionalOnClass(NettyServerCustomizer::class)
    fun nettyServerCustomizer(logbook: Logbook, braveHttpServerTracing: BraveHttpServerTracing): NettyServerCustomizer =
        NettyServerCustomizer { httpServer ->
            httpServer.observe(braveHttpServerTracing)
            httpServer.doOnConnection {
                it.addHandlerLast(LogbookServerHandler(logbook))
            }
        }

Also, side thing, I had to manually include reactor-netty-http-brave in my Gradle file as it's not present in the Reactor bom. I wasn't sure if this was supposed to be there yet I just wanted to call it out.

@btkelly I'm working on some changes in the API. Let me finish that and I'll check the sample app.

@btkelly Several fixes for the example are needed
I don't now why but I needed to add all Reactor Netty modules
build.gradle
    implementation 'io.projectreactor.netty:reactor-netty-core:1.0.0-SNAPSHOT'
    implementation 'io.projectreactor.netty:reactor-netty-http:1.0.0-SNAPSHOT'
    implementation 'io.projectreactor.netty:reactor-netty-http-brave:1.0.0-SNAPSHOT'

The instrumentation for the client is still a PR so you cannot add this
            val httpClient = HttpClient.create()
                //.observe(braveHttpServerTracing)

The instrumentation on the server for the moment is with childObserve and not observe (this will change as I mentioned in my previous comment that I'm going to change the API - I might result in something like decorateHttpClient and decorateHttpServer)
        NettyServerCustomizer { httpServer ->
            httpServer.childObserve(braveHttpServerTracing)
                      .doOnConnection {
                it.addHandlerLast(LogbookServerHandler(logbook))
            }
        }

How do you request the application?

Thanks for looking into this @violetagg, good to know about the client as I was seeing some strange behavior there. As for the childObserve I tried it with both it resulted in the same behavior.
When you are asking How do you request the application? do you mean making an http request?
If so, you can run the app by executing ./gradlew clean bootRun from the root directory and using a REST client to make a GET request to http://localhost:8080/local and see what gets printed out in the logs.

@violetagg You might have also been asking for access to the repo, I added you as a collaborator to the sample app. Feel free to poke around and change whatever as it's just a sample to test this specific issue.

@violetagg Just checking back in on this. I saw that reactor netty 1.0.0 has been released and was curious if this issue resolution was included in that or not. If so I can run through some tests to verify. Let me know when you get second.

Hello!!
I've tried with io.projectreactor.netty:reactor-netty-http-brave:1.0.3 and Sleuth data is not present when logging with Lombok.
@Configuration
class LogbookNettyConfiguration {

    @Bean
    fun reactorNettyHttpTracing(httpTracing: HttpTracing): ReactorNettyHttpTracing = ReactorNettyHttpTracing.create(httpTracing)

    @Bean
    fun logbookNettyServerCustomizer(logbook: Logbook, tracing: ReactorNettyHttpTracing): NettyServerCustomizer {
        return NettyServerCustomizer { httpServer: HttpServer ->
            tracing.decorateHttpServer(httpServer).doOnConnection { it.addHandlerLast(LogbookServerHandler(logbook)) }
        }
    }
}

I will continue with some testing!

@enrique-ninetynine can you show the logs that are missing this information? Also can you show us how you're the reactor netty part?

I've created a really simple Spring Boot application to reproduce the problem!
package com.example.demo

import brave.http.HttpTracing
import org.slf4j.LoggerFactory
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
import org.springframework.boot.web.embedded.netty.NettyServerCustomizer
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController
import org.zalando.logbook.Logbook
import org.zalando.logbook.netty.LogbookServerHandler
import reactor.netty.http.brave.ReactorNettyHttpTracing
import reactor.netty.http.server.HttpServer

@SpringBootApplication
class DemoApplication

fun main(args: Array<String>) {
    runApplication<DemoApplication>(*args)
}

@RestController
@RequestMapping("/test")
class TestController {

    private val logger = LoggerFactory.getLogger(javaClass)

    @GetMapping
    fun test(): SomeResponse {
        logger.info("this trace has trace id")
        return SomeResponse()
    }
}

data class SomeResponse(val someValue: String = "VALUE")

@Configuration
class LogbookNettyConfiguration {

    @Bean
    fun reactorNettyHttpTracing(httpTracing: HttpTracing): ReactorNettyHttpTracing =
        ReactorNettyHttpTracing.create(httpTracing)

    @Bean
    fun logbookNettyServerCustomizer(logbook: Logbook, tracing: ReactorNettyHttpTracing): NettyServerCustomizer {
        return NettyServerCustomizer { httpServer: HttpServer ->
            tracing.decorateHttpServer(httpServer).doOnConnection { it.addHandlerLast(LogbookServerHandler(logbook)) }
        }
    }

}

2021-02-05 13:20:35.652  INFO [tracing-demo,b72979e146fa6425,b72979e146fa6425] 14010 --- [ctor-http-nio-2] com.example.demo.TestController          : this trace has trace id
2021-02-05 13:20:35.757 TRACE [tracing-demo,,] 14010 --- [ctor-http-nio-2] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"9445fad082578d5d","protocol":"HTTP/1.1","remote":"/[0:0:0:0:0:0:0:1]:65185","method":"GET","uri":"http://localhost:8080/test","host":"localhost:8080","path":"/test","scheme":"http","port":null,"headers":{"Accept":["*/*"],"Host":["localhost:8080"],"User-Agent":["curl/7.64.1"]}}
2021-02-05 13:20:35.765 TRACE [tracing-demo,,] 14010 --- [ctor-http-nio-2] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"9445fad082578d5d","duration":162,"protocol":"HTTP/1.1","status":200,"headers":{"Content-Length":["21"],"Content-Type":["application/json"]},"body":{"someValue":"VALUE"}}

I have updated reactor-netty-http-brave to 1.0.4 and spring-boot to 2.4.3 with the same results. Maybe it helps.

Seems like the issue still persists in:

Spring Boot 2.4.4
Spring Cloud 2020.0.2
Logbook Spring Boot Webflux autoconfigure 2.6.1

Please create a sample that reproduces the problem. We have successfully with @violetagg managed to solve the issue so we need to see what changed in the meantime

@mantoshelis The fix in Reactor Netty is still not released https://github.com/reactor/reactor-netty/pull/1555
Please try with 1.0.6-SNAPSHOT (https://repo.spring.io/snapshot)

1.0.6-SNAPSHOT does not provide the expected result also.
I created sample to reproduce the problem: https://github.com/mantoshelis/scs-1690

Please try spring cloud 2020.0.3-SNAPSHOT (notice the 3.0.3 milestone on this issue)

@mantoshelis Can you try again Reactor Netty 1.0.6-SNAPSHOT? I added one additional commit.
Also I would like to mention that in the sample you need to add the code below otherwise the HttpClient's Brave support is not enabled:
  @Bean
  ReactorNettyHttpTracing reactorNettyHttpTracing(HttpTracing httpTracing) {
    return ReactorNettyHttpTracing.create(httpTracing);
  }

  @Bean
  WebClient webClient(Logbook logbook, ReactorNettyHttpTracing tracing) {
    return WebClient.builder()
        .clientConnector(
            new ReactorClientHttpConnector(
                tracing.decorateHttpClient(
                        HttpClient.create()
                                .doOnConnected(conn -> conn.addHandlerLast(new LogbookClientHandler(logbook))))))
        .build();
  }

Yes, it works for the Webclient. Thanks.
Unfortunately, span and trace ids are missing for request / responses to service (Netty container). Is there anything I can do?
2021-04-07 17:49:37.885 TRACE [,,] 356044 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"827845965856ec2c","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:50486","method":"POST","uri":"http://localhost:8080/users","host":"localhost:8080","path":"/users","scheme":"http","port":null,"headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["787e6355-6e91-438d-a4dc-2c6b1dcd3e0d"],"User-Agent":["PostmanRuntime/7.26.10"]},"body":{"password":"any123"}} 2021-04-07 17:49:38.119 TRACE [,a5344328f486e24a,a5344328f486e24a] 356044 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"92a7bea535b43269","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"http://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"http","port":null,"headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.6-SNAPSHOT"],"X-B3-ParentSpanId":["a5344328f486e24a"],"X-B3-Sampled":["1"],"X-B3-SpanId":["f40a0b6f7442ecff"],"X-B3-TraceId":["a5344328f486e24a"]}} 2021-04-07 17:49:38.298 TRACE [,a5344328f486e24a,a5344328f486e24a] 356044 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"92a7bea535b43269","duration":180,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["63c4104d6c0e4e8c-FRA"],"cf-request-id":["094e68845c00004e8c94238000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Wed, 07 Apr 2021 14:49:38 GMT"],"ETag":["W/\"475-dUln65vDgWO1nKVq7E3CyhEz9G4\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"max_age\":604800,\"report_to\":\"cf-nel\"}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report?s=%2FZl8pvYBqj6CJp45zJI3OtGFtNuQ1rimNz8FUuHD6aKYePLffQPbs1G7wytZd7QiyQic4wA02YYABigQDerips3S%2BrGKRa25vpBUVl7I\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Set-Cookie":["__cfduid=dfc893ad89d371df4a0aefb05101c68141617806978; expires=Fri, 07-May-21 14:49:38 GMT; path=/; domain=.randomuser.me; HttpOnly; SameSite=Lax"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"male","name":{"title":"Mr","first":"Lenni","last":"Leppo"},"location":{"street":{"number":5339,"name":"Otavalankatu"},"city":"Äänekoski","state":"Lapland","country":"Finland","postcode":68153,"coordinates":{"latitude":"-10.7265","longitude":"-7.1168"},"timezone":{"offset":"+3:30","description":"Tehran"}},"email":"lenni.leppo@example.com","login":{"uuid":"88988f4a-4506-4cb8-91f4-eff57fb133d2","username":"whiteelephant903","password":"asdfghj","salt":"rwayUTIg","md5":"5b8471bf152d1918c226acd12ca666ce","sha1":"fbdd30281d1fd7993478ffe387a94612e6c419f2","sha256":"6f3f6ffe76a7a5052b9932042a36be7891cea7012d67dbac002ba6a67f481f43"},"dob":{"date":"1995-08-06T08:01:39.518Z","age":26},"registered":{"date":"2019-03-12T07:21:36.996Z","age":2},"phone":"05-970-128","cell":"041-590-26-00","id":{"name":"HETU","value":"NaNNA315undefined"},"picture":{"large":"https://randomuser.me/api/portraits/men/33.jpg","medium":"https://randomuser.me/api/portraits/med/men/33.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/men/33.jpg"},"nat":"FI"}],"info":{"seed":"a89664ceb7e78b3f","results":1,"page":1,"version":"1.3"}}} 2021-04-07 17:49:38.301  INFO [,a5344328f486e24a,a5344328f486e24a] 356044 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user whiteelephant903 with request: Function.CreateUserRequest(password=any123) 2021-04-07 17:49:38.309 TRACE [,,] 356044 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"827845965856ec2c","duration":774,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

@mantoshelis and you enabled the tracing on the server? (similar to what I pasted above for the client)

I added the following code to decore HTTP server:
  @Bean
  NettyServerCustomizer nettyServerCustomizer(ReactorNettyHttpTracing reactorNettyHttpTracing) {
    return reactorNettyHttpTracing::decorateHttpServer;
  }

As a result, inconsistent span and trace ids are added to the request. The response still misses span and trace ids.
REQUEST TO SERVER -> 2021-04-07 18:22:21.684 TRACE [,dcb21254920fb2e3,dcb21254920fb2e3] 377801 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"9c2d88829abbb81f","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:51990","method":"POST","uri":"http://localhost:8080/users","host":"localhost:8080","path":"/users","scheme":"http","port":null,"headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["96a77d5f-c084-4f05-8821-53194b1bb0bc"],"User-Agent":["PostmanRuntime/7.26.10"]},"body":{"password":"any123"}}
REQUEST USING WEBCLIEN -> 2021-04-07 18:22:21.890 TRACE [,5a9cd317672abe37,5a9cd317672abe37] 377801 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"cc960edb23045093","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"http://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"http","port":null,"headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.6-SNAPSHOT"],"X-B3-ParentSpanId":["5a9cd317672abe37"],"X-B3-Sampled":["0"],"X-B3-SpanId":["f0813d55a1391400"],"X-B3-TraceId":["5a9cd317672abe37"]}}
RESPONSE USING WEBLICENT -> 2021-04-07 18:22:22.074 TRACE [,5a9cd317672abe37,5a9cd317672abe37] 377801 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"cc960edb23045093","duration":184,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["63c4403efa01d443-HAM"],"cf-request-id":["094e867b580000d443b5072000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Wed, 07 Apr 2021 15:22:22 GMT"],"ETag":["W/\"47e-WSCSAAFwxIuG45wjMY8z3hxItp4\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"group\":\"cf-nel\",\"max_age\":604800,\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report?s=35TueYtr9yMHDylUwxwXL3Gv%2F988%2B6dl%2BXEYQQzQbdOrhsN9TRHuDqFgcj14NOx6J3tucNePDmQ9ifznZ4d70eiRIgWe19j7lDIXftzZ\"}]}"],"Server":["cloudflare"],"Set-Cookie":["__cfduid=dbc1531e18f1a5a0f25d4576add1076ab1617808941; expires=Fri, 07-May-21 15:22:21 GMT; path=/; domain=.randomuser.me; HttpOnly; SameSite=Lax"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"female","name":{"title":"Ms","first":"Rose","last":"Patel"},"location":{"street":{"number":6235,"name":"Dufferin St"},"city":"Tecumseh","state":"Prince Edward Island","country":"Canada","postcode":"Y5V 1U5","coordinates":{"latitude":"-64.4085","longitude":"168.2848"},"timezone":{"offset":"-11:00","description":"Midway Island, Samoa"}},"email":"rose.patel@example.com","login":{"uuid":"ebf096eb-d337-47ec-837e-fbbe6167ad79","username":"tinywolf756","password":"john1","salt":"ooBE4XWm","md5":"e685eef9f0b1dc1d3aa0146f581e4af7","sha1":"b0bc808ccb00dabd4e9bee131b240b09018df4b4","sha256":"65e794fe1b690eecbee9a9973bf621ddd862020dce2f6d880383f603f2e23b19"},"dob":{"date":"1983-04-30T18:04:16.844Z","age":38},"registered":{"date":"2017-10-17T14:09:41.222Z","age":4},"phone":"044-684-5159","cell":"857-040-2720","id":{"name":"","value":null},"picture":{"large":"https://randomuser.me/api/portraits/women/40.jpg","medium":"https://randomuser.me/api/portraits/med/women/40.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/women/40.jpg"},"nat":"CA"}],"info":{"seed":"a5e3a55e844b57fb","results":1,"page":1,"version":"1.3"}}}
LOGGING IN SERVER -> 2021-04-07 18:22:22.078  INFO [,5a9cd317672abe37,5a9cd317672abe37] 377801 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user tinywolf756 with request: Function.CreateUserRequest(password=any123)
RESPONSE FROM SERVER -> 2021-04-07 18:22:22.086 TRACE [,,] 377801 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"9c2d88829abbb81f","duration":713,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

@mantoshelis Ok let me check that again in Reactor Netty

Hey guys, sorry for commenting on this already closed issue, but the Netty Server Response trace and span are still not working for me:
Maybe you can help me find if I'm missing something, please?
TESTING LOGGING ->
2021-05-28 09:45:58.651  INFO [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-2] v.m.q.m.book.controllers.BookController  : just testing log
NETTY SERVER REQUEST ->
2021-05-28 09:45:58.829 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-2] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"caef6f10cc6755d9","protocol":"HTTP/1.1","remote":"/[0:0:0:0:0:0:0:1%0]:43008","method":"GET","uri":"http://localhost:8080/api/v1/traceId/test", "host":"localhost","path":"/api/v1/traceId/test","scheme":"http","port":"8080","headers":{"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7"],"Cache-Control":["max-age=0"],"Connection":["keep-alive"],"Cookie":["SESSION=46cac22c-d2c5-4188-b707-ca2b9deba7a8"],"Host":["localhost:8080"],"sec-ch-ua":["" Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90""],"sec-ch-ua-mobile":["?0"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"]}}
WEBCLIENT REQUEST ->
2021-05-28 09:45:59.866 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-4] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"e69236c60fd80335","protocol":"HTTP/1.1","remote":"run.mocky.io/<IP_ADDRESS>:443","method":"GET","uri":"https://run.mocky.io/v3/d24fe35c-265d-444a-a609-38f7265c390c" ,"host":"run.mocky.io","path":"/v3/d24fe35c-265d-444a-a609-38f7265c390c","scheme":"https","port":"443","headers":{"accept":["/"],"host":["run.mocky.io"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["901fe3e2450c2868"],"X-B3-Sampled":["0"],"X-B3-SpanId":["83de4c085f55926d"],"X-B3-TraceId":["901fe3e2450c2868"]}}
WEBCLIENT RESPONSE ->
2021-05-28 09:46:00.139 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-4] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"e69236c60fd80335","duration":267,"protocol":"HTTP/1.1","status":200,"headers":{"content-length":["25"],"Content-Type":["application/json; charset=UTF-8"],"Date":["Fri, 28 May 2021 12:45:59 GMT"],"Sozu-Id":["01F6SG52ZCK9TQ8PSRZ0YJZGGQ"]},"body":{"sabor":"queijo"}}
NETTY SERVER RESPONSE - >
2021-05-28 09:46:00.155 TRACE [,,] 142577 --- [or-http-epoll-2] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"caef6f10cc6755d9","duration":1572,"protocol":"HTTP/1.1","status":200,"headers":{"Content-Length":["18"],"Content-Type":["application/json"],"context-path":["http://localhost:8080/api/v1/traceId/test"],"method":["GET"],"trace-id":["901fe3e2450c2868"]},"body":{"sabor":"queijo"}}
I as i bolded in the Netty Server response, I was able to create a new header using the correct trace-id from the Context, but it's still not showing up in the "TRACE [,,]" section and I don't know why.
  @Autowired
  Tracer tracer;

  @Override
  public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
      exchange.getResponse()
              .getHeaders()
              .addAll(additionalHeaders(exchange));
      return chain.filter(exchange);
  }

  private MultiValueMap<String, String> additionalHeaders(ServerWebExchange exchange) {

      MultiValueMap<String, String> mhm = new LinkedMultiValueMap<String, String>();
      mhm.add("method", exchange.getRequest().getMethodValue());
      mhm.add("context-path", exchange.getRequest().getURI().toString());
      mhm.add("trace-id", tracer.currentSpan().context().traceIdString());

      return mhm;
  }

Configurations:
@Bean
NettyServerCustomizer nettyServerCustomizer(ReactorNettyHttpTracing reactorNettyHttpTracing) {
    return reactorNettyHttpTracing::decorateHttpServer;
}

@Bean
ReactorNettyHttpTracing reactorNettyHttpTracing(HttpTracing httpTracing) {
    return ReactorNettyHttpTracing.create(httpTracing);
}

@Bean
WebClient.Builder webClient(Logbook logbook, ReactorNettyHttpTracing tracing) {
    return WebClient.builder()
            .clientConnector(
                new ReactorClientHttpConnector(
                    tracing.decorateHttpClient(
                        HttpClient.create()
                            .doOnConnected(conn -> conn.addHandlerLast(new LogbookClientHandler(logbook))))));
}

I'm using the following versions:
Spring Boot 2.4.5
Spring Cloud 2020.0.3-SNAPSHOT
Logbook Spring Boot Webflux autoconfigure 2.9.0
Reactor Netty 1.0.7
Reactor Netty Http 1.0.7
Reactor Netty Http Brave 1.0.7

@violetagg
Hey guys, sorry for commenting on this already closed issue, but the Netty Server Response trace and span are still not working for me:
Maybe you can help me find if I'm missing something, please?
TESTING LOGGING ->
2021-05-28 09:45:58.651 INFO [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-2] v.m.q.m.book.controllers.BookController : just testing log
NETTY SERVER REQUEST ->
2021-05-28 09:45:58.829 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-2] org.zalando.logbook.Logbook : {"origin":"remote","type":"request","correlation":"caef6f10cc6755d9","protocol":"HTTP/1.1","remote":"/[0:0:0:0:0:0:0:1%0]:43008","method":"GET","uri":"http://localhost:8080/api/v1/traceId/test", "host":"localhost","path":"/api/v1/traceId/test","scheme":"http","port":"8080","headers":{"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7"],"Cache-Control":["max-age=0"],"Connection":["keep-alive"],"Cookie":["SESSION=46cac22c-d2c5-4188-b707-ca2b9deba7a8"],"Host":["localhost:8080"],"sec-ch-ua":["" Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90""],"sec-ch-ua-mobile":["?0"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36"]}}
WEBCLIENT REQUEST ->
2021-05-28 09:45:59.866 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-4] org.zalando.logbook.Logbook : {"origin":"local","type":"request","correlation":"e69236c60fd80335","protocol":"HTTP/1.1","remote":"run.mocky.io/<IP_ADDRESS>:443","method":"GET","uri":"https://run.mocky.io/v3/d24fe35c-265d-444a-a609-38f7265c390c" ,"host":"run.mocky.io","path":"/v3/d24fe35c-265d-444a-a609-38f7265c390c","scheme":"https","port":"443","headers":{"accept":["/"],"host":["run.mocky.io"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["901fe3e2450c2868"],"X-B3-Sampled":["0"],"X-B3-SpanId":["83de4c085f55926d"],"X-B3-TraceId":["901fe3e2450c2868"]}}
WEBCLIENT RESPONSE ->
2021-05-28 09:46:00.139 TRACE [,901fe3e2450c2868,901fe3e2450c2868] 142577 --- [or-http-epoll-4] org.zalando.logbook.Logbook : {"origin":"remote","type":"response","correlation":"e69236c60fd80335","duration":267,"protocol":"HTTP/1.1","status":200,"headers":{"content-length":["25"],"Content-Type":["application/json; charset=UTF-8"],"Date":["Fri, 28 May 2021 12:45:59 GMT"],"Sozu-Id":["01F6SG52ZCK9TQ8PSRZ0YJZGGQ"]},"body":{"sabor":"queijo"}}
NETTY SERVER RESPONSE - >
2021-05-28 09:46:00.155 TRACE [,,] 142577 --- [or-http-epoll-2] org.zalando.logbook.Logbook : {"origin":"local","type":"response","correlation":"caef6f10cc6755d9","duration":1572,"protocol":"HTTP/1.1","status":200,"headers":{"Content-Length":["18"],"Content-Type":["application/json"],"context-path":["http://localhost:8080/api/v1/traceId/test"],"method":["GET"],"trace-id":["901fe3e2450c2868"]},"body":{"sabor":"queijo"}}
I as i bolded in the Netty Server response, I was able to create a new header using the correct trace-id from the Context, but it's still not showing up in the "TRACE [,,]" section and I don't know why.
  @Autowired
  Tracer tracer;

  @Override
  public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
      exchange.getResponse()
              .getHeaders()
              .addAll(additionalHeaders(exchange));
      return chain.filter(exchange);
  }

  private MultiValueMap<String, String> additionalHeaders(ServerWebExchange exchange) {

      MultiValueMap<String, String> mhm = new LinkedMultiValueMap<String, String>();
      mhm.add("method", exchange.getRequest().getMethodValue());
      mhm.add("context-path", exchange.getRequest().getURI().toString());
      mhm.add("trace-id", tracer.currentSpan().context().traceIdString());

      return mhm;
  }

Configurations:
@Bean
NettyServerCustomizer nettyServerCustomizer(ReactorNettyHttpTracing reactorNettyHttpTracing) {
    return reactorNettyHttpTracing::decorateHttpServer;
}

@Bean
ReactorNettyHttpTracing reactorNettyHttpTracing(HttpTracing httpTracing) {
    return ReactorNettyHttpTracing.create(httpTracing);
}

@Bean
WebClient.Builder webClient(Logbook logbook, ReactorNettyHttpTracing tracing) {
    return WebClient.builder()
            .clientConnector(
                new ReactorClientHttpConnector(
                    tracing.decorateHttpClient(
                        HttpClient.create()
                            .doOnConnected(conn -> conn.addHandlerLast(new LogbookClientHandler(logbook))))));
}

I'm using the following versions:
Spring Boot 2.4.5
Spring Cloud 2020.0.3-SNAPSHOT
Logbook Spring Boot Webflux autoconfigure 2.9.0
Reactor Netty 1.0.7
Reactor Netty Http 1.0.7
Reactor Netty Http Brave 1.0.7

Same for me. I'm waiting for Spring Cloud 2020.3 release. I hope the problem will be fixed there.

I have updated to Spring Cloud 2020.0.3 and Spring Boot 2.5.0 (tried with 2.4.6 also) but it still doesn't work. Any news on this?
Dependencies:
Spring Boot 2.5.0
Spring Cloud 2020.0.3
Logbook Webflux Autoconfigure 2.9.0
Reactor Netty 1.0.7
Configuration:
  @Bean
  NettyServerCustomizer nettyServerCustomizer(ReactorNettyHttpTracing reactorNettyHttpTracing) {
    return reactorNettyHttpTracing::decorateHttpServer;
  }

  @Bean
  ReactorNettyHttpTracing reactorNettyHttpTracing(HttpTracing httpTracing) {
    return ReactorNettyHttpTracing.create(httpTracing);
  }

  @Bean
  WebClient webClient(Logbook logbook, ReactorNettyHttpTracing tracing) {
    return WebClient.builder()
        .baseUrl("https://randomuser.me")
        .clientConnector(
            new ReactorClientHttpConnector(
                tracing.decorateHttpClient(
                    HttpClient.create()
                        .doOnConnected(
                            conn -> conn.addHandlerLast(new LogbookClientHandler(logbook))))))
        .build();
  }

Usage:
  private Mono<ServerResponse> createUser(ServerRequest serverRequest) {
    return serverRequest
        .bodyToMono(CreateUserRequest.class)
        .zipWith(getUsername())
        .doOnSuccess(
            tuple -> {
              var request = tuple.getT1();
              var username = tuple.getT2();
              log.info("Creating user {} with request: {}", username, request);
            })
        .then(ServerResponse.noContent().build());
  }

Result on first request (after startup):
2021-05-31 17:38:15.571 TRACE [,d556099056b1b16e,d556099056b1b16e] 104168 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"8e3c77ac28f6571e","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:60730","method":"POST","uri":"http://localhost:8080/users","host":"localhost","path":"/users","scheme":"http","port":"8080","headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["189d0dc1-af6b-4157-a66c-55195f271dfa"],"User-Agent":["PostmanRuntime/7.28.0"]},"body":{"password":"any123"}}
2021-05-31 17:38:15.781 TRACE [,d556099056b1b16e,d556099056b1b16e] 104168 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"d3416c378976b3b0","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"https://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"https","port":"443","headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["d556099056b1b16e"],"X-B3-Sampled":["0"],"X-B3-SpanId":["ee5dbbe97f155dea"],"X-B3-TraceId":["d556099056b1b16e"]}}
2021-05-31 17:38:16.141 TRACE [,d556099056b1b16e,d556099056b1b16e] 104168 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"d3416c378976b3b0","duration":360,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["6580f1e4c9a315e0-ARN"],"cf-request-id":["0a647582fe000015e07fb6e000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Mon, 31 May 2021 14:38:15 GMT"],"ETag":["W/\"47d-lYrcOL6PJvw/4dJ3Q6xmTwrBjOI\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v2?s=RLzzp%2FD5h%2B8NLr9pXuLF3V14y0lXdTV92k0O6osa2TXvsfagreiW9Z0SjoWgUcDE9T6xIJd8QFoS4H5SKduJ7xR8oMAHx5CQOUjSNYIp211a%2FGboeGEwXU%2BeqA%3D%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"female","name":{"title":"Ms","first":"Tessel","last":"Doeleman"},"location":{"street":{"number":7553,"name":"Hintham"},"city":"Rottum Fr","state":"Drenthe","country":"Netherlands","postcode":91747,"coordinates":{"latitude":"42.4965","longitude":"148.2569"},"timezone":{"offset":"+5:45","description":"Kathmandu"}},"email":"tessel.doeleman@example.com","login":{"uuid":"e2fccbb0-e5a5-406b-978f-9f638ddec51d","username":"whitemeercat974","password":"life","salt":"tPvdzSJB","md5":"43af2e462fd74c09159ab6124a1976aa","sha1":"9032bc3fe6bb6ba9edb7f480ca294ae23e1f84a9","sha256":"cb9d557ebda20ae8c52a804a8f994e06a16cb33dd19a881128617e8fb2558d0f"},"dob":{"date":"1967-02-08T21:53:59.286Z","age":54},"registered":{"date":"2006-05-24T19:45:01.211Z","age":15},"phone":"(888)-730-8626","cell":"(834)-459-4418","id":{"name":"BSN","value":"97073068"},"picture":{"large":"https://randomuser.me/api/portraits/women/52.jpg","medium":"https://randomuser.me/api/portraits/med/women/52.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/women/52.jpg"},"nat":"NL"}],"info":{"seed":"7318c967e718a78b","results":1,"page":1,"version":"1.3"}}}
2021-05-31 17:38:16.144  INFO [,d556099056b1b16e,d556099056b1b16e] 104168 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user whitemeercat974 with request: Function.CreateUserRequest(password=any123)
2021-05-31 17:38:16.151 TRACE [,,] 104168 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"8e3c77ac28f6571e","duration":1124,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

Result after further requests:
2021-05-31 17:38:42.472 TRACE [,b87c69b844209ab7,b87c69b844209ab7] 104168 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"97192565e8b23685","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:60730","method":"POST","uri":"http://localhost:8080/users","host":"localhost","path":"/users","scheme":"http","port":"8080","headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["94511d54-3ccd-429b-b1f7-fb947228f5a7"],"User-Agent":["PostmanRuntime/7.28.0"]},"body":{"password":"any123"}}
2021-05-31 17:38:42.475 TRACE [,,] 104168 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"ed2186c8c627ef7b","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"https://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"https","port":"443","headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["b87c69b844209ab7"],"X-B3-Sampled":["0"],"X-B3-SpanId":["fbd839e6bc72f0c6"],"X-B3-TraceId":["b87c69b844209ab7"]}}
2021-05-31 17:38:42.692 TRACE [,,] 104168 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"ed2186c8c627ef7b","duration":217,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["6580f28be84315e0-ARN"],"cf-request-id":["0a6475eb6e000015e08cb8d000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Mon, 31 May 2021 14:38:42 GMT"],"ETag":["W/\"48d-NheyTBJo4DVMZWNKnkXJgMrdny8\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v2?s=bCrYyEgpxApNaKp1Nwa4VBmcZVu9JaJJUHKvAovP01HceJWR3hMxQyw97iqMkI7F%2FbBmE9GTce4iWXOkfAaK2AeabH%2FHFdoSN0sZ0FhXR1KVwk0ECAAv6lA5%2FA%3D%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"male","name":{"title":"Mr","first":"Mattia","last":"Naarden"},"location":{"street":{"number":2454,"name":"Iegepoeledijk"},"city":"Ingelum","state":"Limburg","country":"Netherlands","postcode":32332,"coordinates":{"latitude":"40.3320","longitude":"-39.5073"},"timezone":{"offset":"-7:00","description":"Mountain Time (US & Canada)"}},"email":"mattia.naarden@example.com","login":{"uuid":"9723c673-ebed-4ae4-a000-10c62b83e39f","username":"beautifulbear159","password":"18436572","salt":"6S4ZN5pP","md5":"66813116670b77421dd0fc362a33ca94","sha1":"08a0de90070d530ce8cc372eaa522477335d1f79","sha256":"788018b47ca76bdb8f620aaff02f31af9c3df40fe8503f04d885b03d139d0f0e"},"dob":{"date":"1945-07-23T21:47:47.687Z","age":76},"registered":{"date":"2015-07-24T18:42:00.952Z","age":6},"phone":"(165)-282-5923","cell":"(556)-520-4553","id":{"name":"BSN","value":"23154705"},"picture":{"large":"https://randomuser.me/api/portraits/men/43.jpg","medium":"https://randomuser.me/api/portraits/med/men/43.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/men/43.jpg"},"nat":"NL"}],"info":{"seed":"7ec16e47a96bd729","results":1,"page":1,"version":"1.3"}}}
2021-05-31 17:38:42.694  INFO [,b87c69b844209ab7,b87c69b844209ab7] 104168 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user beautifulbear159 with request: Function.CreateUserRequest(password=any123)
2021-05-31 17:38:42.695 TRACE [,,] 104168 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"97192565e8b23685","duration":229,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

@mantoshelis
If you add LogbookServerHandler do you see the trace ids?
    @Bean
    NettyServerCustomizer nettyServerCustomizer(Logbook logbook, ReactorNettyHttpTracing reactorNettyHttpTracing) {
        return server -> reactorNettyHttpTracing.decorateHttpServer(
                server.doOnConnection(conn -> conn.addHandlerFirst(new LogbookServerHandler(logbook))));
    }

@mantoshelis
If you add LogbookServerHandler do you see the trace ids?
    @Bean
    NettyServerCustomizer nettyServerCustomizer(Logbook logbook, ReactorNettyHttpTracing reactorNettyHttpTracing) {
        return server -> reactorNettyHttpTracing.decorateHttpServer(
                server.doOnConnection(conn -> conn.addHandlerFirst(new LogbookServerHandler(logbook))));
    }

It's only works on first request (after startup):
2021-06-04 10:00:43.987 TRACE [,b3ab223b72ad3db2,b3ab223b72ad3db2] 7146 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"d643fe28629d2a35","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:52386","method":"POST","uri":"http://localhost:8080/users","host":"localhost","path":"/users","scheme":"http","port":"8080","headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["2334cf3d-060e-4995-8798-bbcce35c3e3c"],"User-Agent":["PostmanRuntime/7.28.0"]},"body":{"password":"any123"}}
2021-06-04 10:00:44.335 TRACE [,b3ab223b72ad3db2,b3ab223b72ad3db2] 7146 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"bebbbdfde584682f","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"https://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"https","port":"443","headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["b3ab223b72ad3db2"],"X-B3-Sampled":["0"],"X-B3-SpanId":["d7f95d3ff35e57e2"],"X-B3-TraceId":["b3ab223b72ad3db2"]}}
2021-06-04 10:00:44.621 TRACE [,b3ab223b72ad3db2,b3ab223b72ad3db2] 7146 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"bebbbdfde584682f","duration":290,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400, h3=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["659f49311bcb4180-HAM"],"cf-request-id":["0a776c12b400004180e90b8000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Fri, 04 Jun 2021 07:00:44 GMT"],"ETag":["W/\"473-Sw4VeEmnADQH00fiA6gxGcqnO7o\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v2?s=pHqfAT5qGuC%2BkX7r3xbsbc0qYRV1lmUIszsizXGXDYYU50Kfg0pDKQEE5NLSNefp%2F5sWU99NK72PLtFA0IEVcsIL3OaNkiEaEFROe4q%2FCUfJ76URj1PGJGI3ig%3D%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"male","name":{"title":"Mr","first":"Niklas","last":"Jutila"},"location":{"street":{"number":5760,"name":"Esplanadi"},"city":"Lavia","state":"Ostrobothnia","country":"Finland","postcode":19900,"coordinates":{"latitude":"-10.7868","longitude":"-66.1616"},"timezone":{"offset":"-9:00","description":"Alaska"}},"email":"niklas.jutila@example.com","login":{"uuid":"a3291681-aceb-4d82-902a-5a360c2a6870","username":"blackostrich436","password":"1981","salt":"NW3Q2Hkg","md5":"7cec81c02dbde3c300dc2f171cc48fe7","sha1":"4e3fad2b5590357cc39b5d8b3bc9995df616bf61","sha256":"cf3edc1889511e17555bfc478aa6f48682b575f74d2520807cb7fc1b2c062394"},"dob":{"date":"1979-07-01T15:49:46.241Z","age":42},"registered":{"date":"2006-02-25T01:59:43.823Z","age":15},"phone":"02-716-454","cell":"040-089-45-43","id":{"name":"HETU","value":"NaNNA203undefined"},"picture":{"large":"https://randomuser.me/api/portraits/men/41.jpg","medium":"https://randomuser.me/api/portraits/med/men/41.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/men/41.jpg"},"nat":"FI"}],"info":{"seed":"66b0e637edd60ba8","results":1,"page":1,"version":"1.3"}}}
2021-06-04 10:00:44.629  INFO [,b3ab223b72ad3db2,b3ab223b72ad3db2] 7146 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user blackostrich436 with request: Function.CreateUserRequest(password=any123)
2021-06-04 10:00:44.649 TRACE [,b3ab223b72ad3db2,b3ab223b72ad3db2] 7146 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"d643fe28629d2a35","duration":1404,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

Further requests are missing WebClient trace and span ids:
2021-06-04 10:01:25.045 TRACE [,02b73147bbd2b499,02b73147bbd2b499] 7146 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"9691d7fa83140c01","protocol":"HTTP/1.1","remote":"/0:0:0:0:0:0:0:1%0:52386","method":"POST","uri":"http://localhost:8080/users","host":"localhost","path":"/users","scheme":"http","port":"8080","headers":{"Accept":["*/*"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"content-length":["28"],"Content-Type":["application/json"],"Host":["localhost:8080"],"Postman-Token":["f29694a1-c467-4b8d-b209-6e01a5b5921e"],"User-Agent":["PostmanRuntime/7.28.0"]},"body":{"password":"any123"}}
2021-06-04 10:01:25.047 TRACE [,,] 7146 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"c91e79c4aa42a2df","protocol":"HTTP/1.1","remote":"randomuser.me/<IP_ADDRESS>:443","method":"GET","uri":"https://randomuser.me/api?results=1","host":"randomuser.me","path":"/api","scheme":"https","port":"443","headers":{"Accept":["application/json"],"host":["randomuser.me"],"user-agent":["ReactorNetty/1.0.7"],"X-B3-ParentSpanId":["02b73147bbd2b499"],"X-B3-Sampled":["0"],"X-B3-SpanId":["1abd0192bbed81c7"],"X-B3-TraceId":["02b73147bbd2b499"]}}
2021-06-04 10:01:25.198 TRACE [,,] 7146 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"c91e79c4aa42a2df","duration":149,"protocol":"HTTP/1.1","status":200,"headers":{"Access-Control-Allow-Origin":["*"],"alt-svc":["h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400, h3=\":443\"; ma=86400"],"Cache-Control":["no-cache"],"CF-Cache-Status":["DYNAMIC"],"CF-RAY":["659f4a2f98f84180-HAM"],"cf-request-id":["0a776cb1c300004180d39cd000000001"],"Connection":["keep-alive"],"Content-Type":["application/json; charset=utf-8"],"Date":["Fri, 04 Jun 2021 07:01:25 GMT"],"ETag":["W/\"489-AwLLxpS0zUAjQKoL2NAq+3DYhh8\""],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"NEL":["{\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v2?s=jeBxzqotiqS1z0rYR7jTbGRYUSakK40JONeg%2FAJt%2BF8VO3ceu5yZMRBCgBvWDPpiJpMraa8jrJinTFvjIuWHx0cM%2BfvZ8rQKEP1HupZpSMLVT7cFxMcRi1L%2FQw%3D%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"],"X-Powered-By":["Express"]},"body":{"results":[{"gender":"male","name":{"title":"Mr","first":"Abdulrahman","last":"Hauge"},"location":{"street":{"number":2481,"name":"Øivinds vei"},"city":"Movatn","state":"Sør-Trøndelag","country":"Norway","postcode":"6829","coordinates":{"latitude":"51.8526","longitude":"-159.4957"},"timezone":{"offset":"-3:00","description":"Brazil, Buenos Aires, Georgetown"}},"email":"abdulrahman.hauge@example.com","login":{"uuid":"0453f8b0-d778-4460-bb22-385b8b32d007","username":"blackdog275","password":"popo","salt":"ZEBIrya8","md5":"1e2bef7d01b19ff9e269bc065a6b2ed3","sha1":"da976a325561a2f57d28da3506f0fcc03b472d1e","sha256":"934b2fdb295c74b4d08ee7fadf3e98e68ce5d37423831f80bd68591c56b672ca"},"dob":{"date":"1974-12-25T01:34:26.160Z","age":47},"registered":{"date":"2008-01-03T13:55:31.168Z","age":13},"phone":"67218004","cell":"48108438","id":{"name":"FN","value":"25127402119"},"picture":{"large":"https://randomuser.me/api/portraits/men/73.jpg","medium":"https://randomuser.me/api/portraits/med/men/73.jpg","thumbnail":"https://randomuser.me/api/portraits/thumb/men/73.jpg"},"nat":"NO"}],"info":{"seed":"359d06d949f4a72a","results":1,"page":1,"version":"1.3"}}}
2021-06-04 10:01:25.199  INFO [,02b73147bbd2b499,02b73147bbd2b499] 7146 --- [or-http-epoll-5] com.scs.issue.Function                   : Creating user blackdog275 with request: Function.CreateUserRequest(password=any123)
2021-06-04 10:01:25.201 TRACE [,02b73147bbd2b499,02b73147bbd2b499] 7146 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"9691d7fa83140c01","duration":161,"protocol":"HTTP/1.1","status":204,"headers":{"content-length":["0"]}}

Could it be logbook issue? 🤔

@mantoshelis @sergey-volkov-lm The issue is in Reactor Netty and should be fixed with this PR https://github.com/reactor/reactor-netty/pull/1656. It is related only to HttpClient when a connection pool is in use.

You should be able to try Reactor Netty 1.0.8-SNAPSHOT

It worked out for me(showing the trace-id and span-id in the log), even making multiple requests like @mantoshelis did, but the span-id from the request made with webclient and the response are different. Is It intended, which would work differently from a non-reactive(webflux + webclient) background, or is it not intended?
Request to Netty Server - 2021-06-07 15:45:32.883 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request",...
Request using Webclient - 2021-06-07 15:45:34.084 TRACE [,ca46fa96b70b59a6,d25e19d543f4a02a] 356504 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"local","type":"request",....
Response using Webclient - 2021-06-07 15:45:34.344 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-5] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response",...
Response from Netty Server - 2021-06-07 15:45:34.365 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response",...
Thank you very much for the help!

@alex183 Which version of Spring Sleuth do you use? We have one fix that might be related and it is in the latest available release.

@violetagg
These are my dependencies right now:
Spring Cloud - 2020.0.3
Spring Cloud Sleuth - 3.0.3

Can you please create a simple sample that replicates this problem?

@marcingrzejszczak @violetagg
its on master branch
https://github.com/alex183/spring-cloud-sleuth-issue-1690

It worked out for me(showing the trace-id and span-id in the log), even making multiple requests like @mantoshelis did, but the span-id from the request made with webclient and the response are different. Is It intended, which would work differently from a non-reactive(webflux + webclient) background, or is it not intended?
Request to Netty Server - 2021-06-07 15:45:32.883 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-3] org.zalando.logbook.Logbook : {"origin":"remote","type":"request",...
Request using Webclient - 2021-06-07 15:45:34.084 TRACE [,ca46fa96b70b59a6,d25e19d543f4a02a] 356504 --- [or-http-epoll-5] org.zalando.logbook.Logbook : {"origin":"local","type":"request",....
Response using Webclient - 2021-06-07 15:45:34.344 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-5] org.zalando.logbook.Logbook : {"origin":"remote","type":"response",...
Response from Netty Server - 2021-06-07 15:45:34.365 TRACE [,ca46fa96b70b59a6,ca46fa96b70b59a6] 356504 --- [or-http-epoll-3] org.zalando.logbook.Logbook : {"origin":"local","type":"response",...
Thank you very much for the help!

Yes, same for me. You could also use my sample project as a reproduction source: https://github.com/mantoshelis/scs-1690

Is there any news on this issue?

Not yet. Didn't have time to look into this.

I've enabled wiretapping in my project and I'm encountering the issue that even with adding the TracingHttpClientDecorator via decoreHttpClient(), some wiretap logs do not contain a traceId and spanId because the doOnResponse() method seems to only be called after the HTTP status and headers have already been received.
https://github.com/reactor/reactor-netty/blob/main/reactor-netty-http/src/main/java/reactor/netty/http/client/HttpClientConfig.java#L892
The Javadoc of HttpClientState.RESPONSE_RECEIVED says:

The response status and headers have been received

Seems like the LogbookHandlers aren't affected by that since they read values from the HTTP response object instead of logging every step in the response handling.
My wiretapping configuration:
  @Bean
  public HttpClientCustomizer httpClientWiretapCustomizer() {
    return httpClient -> httpClient.wiretap("WiretapClient", LogLevel.INFO, AdvancedByteBufFormat.TEXTUAL, StandardCharsets.UTF_8);
  }

  @Bean
  public HttpClientCustomizer tracingCustomizer(HttpTracing httpTracing) {
    return httpClient -> ReactorNettyHttpTracing.create(httpTracing).decorateHttpClient(httpClient);
  }

I think a simple httpClient.wiretap(true) should also be enough to reproduce the problem.
Any advice how to fix the spanIds and traceIds for wiretapping?

Hey guys, are there any updates? I faced with the problem on the latest spring boot version. Simple app is this
@Configuration
class Config {
    @Bean
    fun webClient(builder: WebClient.Builder) = builder.build()
}

private val logger = KotlinLogging.logger {}

@RestController
class Controller(
    private val client: WebClient
) {

    private val urls = listOf(
        "https://google.com",
        "https://vk.com",
        "https://reqbin.com/echo"
    )

    @GetMapping("/test")
    fun test(): Mono<Map<String, Int>> {
        return Flux
            .fromIterable(urls)
            .flatMap { performRequest(it) }
            .collectMap({ it.first }, { it.second })
            .doOnNext { logger.info { "Got $it" } }
    }

    fun performRequest(url: String): Mono<Pair<String, Int>> {
        return client.get()
            .uri(url)
            .retrieve()
            .toBodilessEntity()
            .map { url to it.statusCode.value() }
    }
}

pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.6.2</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>ru.nmedvedev</groupId>
    <artifactId>spring-sleuth-logbook</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>spring-sleuth-logbook</name>
    <description>spring-sleuth-logbook</description>
    <properties>
        <java.version>17</java.version>
        <kotlin.version>1.6.10</kotlin.version>
        <spring-cloud.version>2021.0.0</spring-cloud.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.module</groupId>
            <artifactId>jackson-module-kotlin</artifactId>
        </dependency>
        <dependency>
            <groupId>io.projectreactor.kotlin</groupId>
            <artifactId>reactor-kotlin-extensions</artifactId>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-reflect</artifactId>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-stdlib-jdk8</artifactId>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlinx</groupId>
            <artifactId>kotlinx-coroutines-reactor</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        <dependency>
            <groupId>io.github.microutils</groupId>
            <artifactId>kotlin-logging-jvm</artifactId>
            <version>2.1.21</version>
        </dependency>
        <dependency>
            <groupId>org.zalando</groupId>
            <artifactId>logbook-spring-boot-starter</artifactId>
            <version>2.14.0</version>
        </dependency>
        <dependency>
            <groupId>org.zalando</groupId>
            <artifactId>logbook-spring-boot-webflux-autoconfigure</artifactId>
            <version>2.14.0</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.projectreactor</groupId>
            <artifactId>reactor-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <sourceDirectory>${project.basedir}/src/main/kotlin</sourceDirectory>
        <testSourceDirectory>${project.basedir}/src/test/kotlin</testSourceDirectory>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.jetbrains.kotlin</groupId>
                <artifactId>kotlin-maven-plugin</artifactId>
                <configuration>
                    <args>
                        <arg>-Xjsr305=strict</arg>
                    </args>
                    <compilerPlugins>
                        <plugin>spring</plugin>
                    </compilerPlugins>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.jetbrains.kotlin</groupId>
                        <artifactId>kotlin-maven-allopen</artifactId>
                        <version>${kotlin.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>

</project>

So it does not print traceId and spanId in most Logbook logs
2021-12-29 19:07:33.786 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"request","correlation":"f46782d5dad15897","protocol":"HTTP/1.1","remote":"/[0:0:0:0:0:0:0:1%0]:51784","method":"GET","uri":"http://localhost:8080/test","host":"localhost","path":"/test","scheme":"http","port":"8080","headers":{"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["en-US,en;q=0.9"],"Cache-Control":["max-age=0"],"Connection":["keep-alive"],"Host":["localhost:8080"],"sec-ch-ua":["\" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\""],"sec-ch-ua-mobile":["?0"],"sec-ch-ua-platform":["\"Linux\""],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36"]}}
2021-12-29 19:07:33.929 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"e883e5c98e295110","protocol":"HTTP/1.1","remote":"reqbin.com/<IP_ADDRESS>:443","method":"GET","uri":"https://reqbin.com/echo","host":"reqbin.com","path":"/echo","scheme":"https","port":"443","headers":{"accept":["*/*"],"accept-encoding":["gzip"],"host":["reqbin.com"],"user-agent":["ReactorNetty/1.0.14"],"X-B3-ParentSpanId":["21f0e57d9b19689e"],"X-B3-Sampled":["0"],"X-B3-SpanId":["bdf469d48f0de167"],"X-B3-TraceId":["21f0e57d9b19689e"]}}
2021-12-29 19:07:33.963 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"d27c23b9d451e9a1","protocol":"HTTP/1.1","remote":"vk.com/<IP_ADDRESS>:443","method":"GET","uri":"https://vk.com/","host":"vk.com","path":"/","scheme":"https","port":"443","headers":{"accept":["*/*"],"accept-encoding":["gzip"],"host":["vk.com"],"user-agent":["ReactorNetty/1.0.14"],"X-B3-ParentSpanId":["21f0e57d9b19689e"],"X-B3-Sampled":["0"],"X-B3-SpanId":["01f86229ee52d067"],"X-B3-TraceId":["21f0e57d9b19689e"]}}
2021-12-29 19:07:33.977 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"request","correlation":"80fc972e3227bed0","protocol":"HTTP/1.1","remote":"google.com/<IP_ADDRESS>:443","method":"GET","uri":"https://google.com/","host":"google.com","path":"/","scheme":"https","port":"443","headers":{"accept":["*/*"],"accept-encoding":["gzip"],"host":["google.com"],"user-agent":["ReactorNetty/1.0.14"],"X-B3-ParentSpanId":["21f0e57d9b19689e"],"X-B3-Sampled":["0"],"X-B3-SpanId":["95ede5efd1997ba7"],"X-B3-TraceId":["21f0e57d9b19689e"]}}
2021-12-29 19:07:34.005 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"e883e5c98e295110","duration":76,"protocol":"HTTP/1.1","status":200,"headers":{"access-control-allow-origin":["*"],"Age":["275"],"alt-svc":["h3=\":443\"; ma=86400, h3-29=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-27=\":443\"; ma=86400"],"Cache-Control":["max-age=31536000"],"CF-Cache-Status":["HIT"],"CF-RAY":["6c5448351c9400b4-DME"],"Connection":["keep-alive"],"Content-Type":["text/html; charset=utf-8"],"Date":["Wed, 29 Dec 2021 16:07:33 GMT"],"Expect-CT":["max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""],"Last-Modified":["Wed, 29 Dec 2021 14:34:01 GMT"],"NEL":["{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}"],"Report-To":["{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=kGqqNEGS0UEywhcomo3LhbeUtOn4nd3IgZdaUZabOg8cmCjWsiipbln0HyOOkQLU0yyBrcwyZhu03PeSZdVk4%2BkXapFg2zVqwBpYjU0lKRI5aKBR5cJriOD8r%2FoN\"}],\"group\":\"cf-nel\",\"max_age\":604800}"],"Server":["cloudflare"],"Transfer-Encoding":["chunked"],"Vary":["Accept-Encoding"]}}
2021-12-29 19:07:34.012 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"d27c23b9d451e9a1","duration":48,"protocol":"HTTP/1.1","status":302,"headers":{"Access-Control-Expose-Headers":["X-Frontend"],"alt-svc":["h3=\":443\"; ma=86400,h3-29=\":443\"; ma=86400"],"Connection":["keep-alive"],"Content-Type":["text/html; charset=windows-1251"],"Date":["Wed, 29 Dec 2021 16:07:33 GMT"],"Location":["https://m.vk.com/"],"Server":["kittenx"],"Set-Cookie":["remixir=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com; secure; HttpOnly","remixlang=0; expires=Tue, 27 Dec 2022 15:33:48 GMT; path=/; domain=.vk.com"],"Strict-Transport-Security":["max-age=15768000"],"transfer-encoding":["chunked"],"X-Frontend":["front605108"],"X-Powered-By":["KPHP/7.4.109800"]}}
2021-12-29 19:07:34.015 TRACE [,,] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"remote","type":"response","correlation":"80fc972e3227bed0","duration":38,"protocol":"HTTP/1.1","status":301,"headers":{"Alt-Svc":["h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000,h3-Q050=\":443\"; ma=2592000,h3-Q046=\":443\"; ma=2592000,h3-Q043=\":443\"; ma=2592000,quic=\":443\"; ma=2592000; v=\"46,43\""],"Cache-Control":["public, max-age=2592000"],"content-length":["220"],"Content-Type":["text/html; charset=UTF-8"],"Date":["Wed, 29 Dec 2021 16:07:33 GMT"],"Expires":["Fri, 28 Jan 2022 16:07:33 GMT"],"Location":["https://www.google.com/"],"Server":["gws"],"X-Frame-Options":["SAMEORIGIN"],"X-XSS-Protection":["0"]}}
2021-12-29 19:07:34.016  INFO [,21f0e57d9b19689e,21f0e57d9b19689e] 46656 --- [or-http-epoll-3] r.n.s.SpringSleuthLogbookApplication     : Got {https://vk.com=302, https://reqbin.com/echo=200, https://google.com=301}
2021-12-29 19:07:34.026 TRACE [,21f0e57d9b19689e,21f0e57d9b19689e] 46656 --- [or-http-epoll-3] org.zalando.logbook.Logbook              : {"origin":"local","type":"response","correlation":"f46782d5dad15897","duration":567,"protocol":"HTTP/1.1","status":200,"headers":{"Content-Length":["77"],"Content-Type":["application/json"]}}

Thanks for the help on this @violetagg
I was able to get this working:
@Configuration
@Import(LogbookWebFluxAutoConfiguration.class)
public class LogbookConfiguration {

	@Bean
	public LogstashLogbackSink logbackSink(final HttpLogFormatter formatter) {
		return new LogstashLogbackSink(formatter);
	}

	@Bean
	public CorrelationId correlationId(final Tracer tracer) {
		return request -> requireNonNull(requireNonNull(tracer.currentSpan())).context().traceId();
	}

	@Bean
	ReactorNettyHttpTracing reactorNettyHttpTracing(final HttpTracing httpTracing) {
		return ReactorNettyHttpTracing.create(httpTracing);
	}

	@Bean
	NettyServerCustomizer nettyServerCustomizer(final Logbook logbook,
			final ReactorNettyHttpTracing reactorNettyHttpTracing) {
		return server -> reactorNettyHttpTracing.decorateHttpServer(
				server.doOnConnection(conn -> conn.addHandlerFirst(new LogbookServerHandler(logbook))));
	}

	@Bean
	WebClient webClient(final Logbook logbook, final ReactorNettyHttpTracing reactorNettyHttpTracing) {
		return WebClient.builder()
				.clientConnector(new ReactorClientHttpConnector(reactorNettyHttpTracing.decorateHttpClient(HttpClient
						.create().doOnConnected(conn -> conn.addHandlerLast(new LogbookClientHandler(logbook))))))
				.build();
	}

}

Using version:
Spring Cloud Sleuth from spring cloud:
<spring-cloud.version>2021.0.1</spring-cloud.version>
Spring boot version
spring-boot-starter-parent
2.6.7
Zalando dependencies

org.zalando
logbook-spring-boot-webflux-autoconfigure
2.14.0

<dependency>
  <groupId>org.zalando</groupId>
  <artifactId>logbook-logstash</artifactId>
  <version>${logbook.version}</version>
</dependency>

Great, thanks for the update! So is there a bug in Sleuth or not? Cause I'm getting confused if I need to fix sth here or not

Ok, so since in Sleuth we don't want to add new features (3.1.x is the last line of Sleuth) I will document this


IllegalArgumentException on plugin install

We are using ES 1.6.2 and encounter the following exception when we try to install.
command:
/elasticsearch/bin/plugin -install tempest -url https://github.com/datarank/tempest/archive/v1.0.0.zip
result:
-> Installing tempest...
Trying https://github.com/datarank/tempest/archive/v1.0.0.zip...
Downloading .....................................DONE
Installed tempest into /elasticsearch/plugins/tempest
Usage:
-u, --url     [plugin location]   : Set exact URL to download the plugin from
-i, --install [plugin name]       : Downloads and installs listed plugins [*]
-t, --timeout [duration]          : Timeout setting: 30s, 1m, 1h... (infinite by default)
-r, --remove  [plugin name]       : Removes listed plugins
-l, --list                        : List installed plugins
-v, --verbose                     : Prints verbose messages
-s, --silent                      : Run in silent mode
-h, --help                        : Prints this help message
[*] Plugin name could be:
elasticsearch/plugin/version for official elasticsearch plugins (download from download.elasticsearch.org)
groupId/artifactId/version   for community plugins (download from maven central or oss sonatype)
username/repository          for site plugins (download from github master)
Message:
Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation.

I am closing this issue as the release url we were using was incorrect.
This command works for us:
/elasticsearch/bin/plugin --url https://github.com/datarank/tempest/releases/download/v1.0.0/tempest-allocator-1.0.0.zip --install tempest


What's the difference between the Query and Info messages?

Query is a targeted query; it takes arguments. Info is just some prefab response the application gives you to summarize it's current state. We could/should probably just collapse Info into Query

Thank you.


hiding directory from public path

killer release @jenius! apologies if this has already been addressed.
im looking to achieve a simple blog structure with dynamic content. i threw the posts in a folder called logs and was looking to hide that directory from the url, so for example, instead of logs/first-post.html, it would resolve at /first-post.html
i played around with pathologist without any success and wondered what the preferred method of execution would be for this use case.
at the moment, im simply ditching the logs directory, and putting the entries on the root directory. i'm accessing the entries with a each log in site["."] iteration loop which seems to work.
is that what i should be sticking with you think?

Ok so two ways I can see this being worked out:

We're thinking of adding to dynamic content such that you can pass a globstar to it if you want and it will just run that directory. This will probably be added next week and would enable this behavior.

If we added placeholders to charge, it would enable you to rewrite correctly. You can do this with netlify already as shown above, if you want.

very cool, thanks brother

You don't have to close if you don't want. I'll update here when there's a good way to solve this either way!

i just didn't want to clutter up core roots with this issue. a cross reference a dynamic content issue of the same name makes more sense to me.

Cool, feel free to open one up there then if you want!


Fix synthetix tests

Closes #65
I've decided to remove this test case, it's passing sometimes (non-deterministic) here and I haven't to much time to investigate that right now.
Note: I've realized that I was using an old contract address.

Thanks!


Cfspdk 1184 add gecko driver

Zephyr style adc driver for pearl gecko.

Is there any documentation on this? (there needs to be some)
This isn't mergable...
There is a conflict and changes in samples/drivers/adc/src/main.c (we agreed not to modify that sample)
There are compliance and documentation issues as well

I put some documentation into the CFSPDK-1230 Jira ticket in the comments.
I restored samples/drivers/adc/src/main.c to the original.  Did a rebase and signed the commit.  There still seems to be a compliance issue but not sure why.  I did the rebase and merge.


The global prop is not being honored when importing from .css files

Do you want to request a feature or report a bug?
Bug.
What is the current behavior?
The global prop is not being honored when importing from .css files as the docs state:

To consume the styles in your component you can import them from your CSS file and render them using a

you need to tell the webpack loader to compile those styles as global, in this case you can add a comment at the top of the file /* @styled-jsx=global */
More info https://github.com/zeit/styled-jsx#styles-in-regular-css-files

That’s not the issue. The docs state:

Remember to add the global prop if you want your styles to be global.

Adding a comment to the file or configuring the webpack loader works fine.
Adding the global prop does not.
From your response, I’m assuming that the docs have to be updated to say that the global prop is useless when importing from regular css files.

You need both, mind sending a PR to clarify??

You need both what? Does my example repo not illustrate the bug/docs issue well enough?

You need to add the /* @styled-jsx=global */ comment at the top of the file (head.css) and the global prop to the style tag <style jsx global>{ css }</style> (head.js)

the global prop is useless when importing from regular css files

it is not

What technical aspect the the global prop serve? It has no effect from I can see.
Ultimately, the docs regarding the global prop in relation to the new feature of importing regular CSS files is misleading/confusing.
I can submit a PR for updating the docs to clarify. Can you give me an understanding as to what the purpose is of the global prop in this scenario?

That'd be great! styled-jsx transpiles external styles to string objects eg.
const _defaultExport = new String('div  { color: red }')
_defaultExport.__hash = '123'
export default _defaultExport

To each of those objects we also add property called __hash that is an hash of the styles. We use it to identify each ruleset, mount and unmount styles, avoid duplicates and in the case of scoped styles to actually scope them eg. rewrite the css string above todiv.jsx-123 { color: red }
When we detect a style tag that has the jsx attribute we use this information to add a scoped class to every JSX tag.
so this:
import styles from '../my-external-styles'

export default () => (
   <div> howdy
       <style jsx>{styles}</style>
   </div>
)

is transpiled to
import JSXStyle from 'styled-jsx/style'
import styles from '../my-external-styles'

export default () => (
   <div className={`jsx-${styles.__hash}`}> howdy
       <JSXStyle styleId={styles.__hash} css={styles} />
   </div>
)

In the case of global styles this is not necessary, but we need that global prop on the style tag to differentiate between the two cases. Hope this is clear enough.


Allow user specify what kind of data should be downloaded

User should be able to specify what kind of data should be downloaded based on the mime type, for example:

only text (text/*)
text, images (image/*) and videos (video/*)
any kind (*/*).

Sure, I'll take one this right away.
Thanks,
Rajat Pawar
NYU School of Engineering

On Aug 3, 2015, at 10:38 AM, Aécio Santos<EMAIL_ADDRESS>wrote:
User should be able to specify what kind of data should be downloaded based on the mime type, for example:
only text (text/)
text, images (image/) and videos (video/)
any kind (/*).
—
Reply to this email directly or view it on GitHub.


Long vehicles (buses, trucks, etc) giving way when they have right-of-way

So I have several intersections where a Congo-line of buses has accumulated despite the road the buses are coming from has right-of-way over the other directions of traffic. The other roads are all set to yield, yet they constantly flow through until the bus despawns and a shorter vehicle forces it's way though as it should. I've also noticed similar problems happening with cargo trucks in the roundabouts of my industrial district, where they'll momentarily clog up the whole roundabout to give-way to cars entering the roundabout. Fortunately in this case there's enough vehicles of similar length to alleviate the problem.
If you need my save I've posted it in #198

I think multiple things play a role here:

Vehicles do not enter a junction when the lane right behind the junction is occupied. That's of course more likely to be noticable for long vehicles like busses or heavy trucks.
If a vehicle on a give-way road decides to enter the junction vehicles even vehicles on a right-of-way road wait for the first vehicle to leave the junction.
Determining whether two roads are positioned left/right/straight to each other is currently not working properly which causes the priority rules logic to fail: This affects junctions where segments are connected with relative angles of between 0° and 30°, or between 150° and 180°.

The last point will be fixed with the next update. Remaining points are working as intended.


Source map files

Where do I get a source map file like you have

Hi @newhen, sorry for the delay, I missed this notification.
The source map file is up to you to design, if you need it. Because the input card data is an array of json objects that looks something like this:
[
    {
        "rank":"1",
        "source":"AUA Reader AUA Chapter 01",
        "thai": "ดี",
        "english":"To be good."
   },
   {
        "rank":"1",
        "source":"AUA Reader AUA Chapter 02",
        "thai": "หนึ่ง",
        "english":"One, a."
   },
]

If you import this file, it would not have any categories in the resulting Anki deck (because it's be a flat array of cards). If you want categories (in this case, a category for each chapter), you would design a source map like this:
{
    "AUA Reader AUA Chapter 01": {
        "source": "AUA Lessons::Chapter 01"
    },
    "AUA Reader AUA Chapter 02": {
        "source": "AUA Lessons::Chapter 02"
    }
}

This would map the "source" field to an Anki category. The end result is a structured deck like the following:


(forums) Write user stories for registered forum users (Gio and Slovin)

This issue focuses on crafting comprehensive user stories for registered users engaging with the forums on our board games website. We will delve into capturing essential aspects of user interaction, including browsing, engagement, moderation, notifications, profile management, and support. Through these user stories, we aim to meticulously understand and delineate the user’s journey, expectations, and potential challenges, ensuring that the forum development resonates with user needs and preferences. The outcome will be insights that will guide and enhance the robust development and optimization of the forum experience, making it more intuitive, engaging, and user-friendly.

As with unregistered users, I am adding here following user stories on how we can look at possible functionality for registered users:

Sarah logs in and uses the search bar to find discussions on her favorite board game.
Alex creates a new thread, uploading images and writing a review about a game he recently played.
Jamie receives notifications when other users reply to a thread she's active in or mention her username.
Chris bookmarks threads for easy access and organizes them by game genre.
Jordan upvotes a helpful post, appreciating the user's contribution to a discussion.
Taylor reports a comment that violates the forum's guidelines.
Sarah edits her comment in a thread to correct a game rule she previously mis-stated.
Alex deletes one of his older comments that he no longer feels is relevant.
Jamie subscribes to a thread to receive email updates on new replies.
Jordan views the forum's leaderboard, checks top contributors, and aims to increase his participation.

Again, let me know of any possible suggestions to make to this and we can certainly modify!

Since there are no additional comments, I am finalizing these user stories for now and adding them to the wiki. If anyone has any additional comments in the future, we can reopen this issue and visit the stories per need basis.
As for task handling, I came up with the user stories, along with adding them into the wiki. Ben and Ben both edited and came up with the description of the task.

Issue Score: Excellent
Comments:
These are straightforward, functional user stories.
Thank you for adding the closing statement about work distribution!
For future reference if anything is made because of an issue (documentation, pull request, a demo), it is good to include a link to it or at least instruction on where to find it.
So here, you reference making a wiki page, it would be good for you to link said wiki page to this issue.
Overall, good work, keep going!


Paradigm / Comparison Questions about noflo

I have a few questions that may be more around changing the way I fundamentally break down the problem rather than anything else
I have used NodeRed extensively so trying to figure out similarities/differences.
A) Request Response: If I want to set up a graph that response to an incoming query (eg an HTTP request) is the current practice to pass the HTTP Object (in javascript) and send the response at the end?
B) Node Configurations: For example what messages to filter, thresholds, URLs to poll etc. Should these be "injected" via another node at run time? I see a lot of people using something like INPUT.txt -> NODE1
C) Global configurations. Does FPB Protocol have the concepts of global namespace objects?
Generally, I am very impressed with FBP Protocol and the support for multiple run times but just wondering how some other programming concepts such as config files come in to play.

A) For that, noflo-assembly provides a quite nice approach. See especially https://github.com/noflo/noflo-assembly/wiki/Concurrency-handling
B) That's what you'd do with "Initial Information Packets", see http://www.jpaulmorrison.com/fbp/reusparm.shtml
C) There is no global state, all state used by components needs to be passed in via messages


Capabilities Should Not be Accessible via FQN

Capabilities should not be accessible by their fully-qualified name in order to avoid hijacking a module's capability. They should not be qualified at all.

I'm not sure we should disallow this, as there's no reason that e.g. a test wouldn't want to access a cap by FQN. Runtime enforces that cap natives must be called same-module so there is no possible escalation by this method.

This was fixed with 761adfe5dcb93d054e7883a3776c9bf70889f8ae. Closing.


Issue 720 test User.Teams

It is good.
I would like a test array with

a user that does not have teams
a user that has teams
a user that has teams but one/or more of them do not exist.

tests := []struct {
		title string
		teams []testTeam
	}

How is it possible to test this?

a user that has teams but one/or more of them do not exist.

the user that a list of teamIds so you can alter that list.

ok I see but is it right to do this because I rely on team.Join to test user.Teams and it is the job of team.Join to manage the list of teamIds.

yes, it is only to test the errors, so use it on a user that you do not use to test elsewhere

or  if you don't save the user after you should be alright

user.Teams does not return an error. A slice of team pointers is returned.

you can test that the size of the slice does not match the size of the teamIds

Ok.

:+1:


Rewrite low/high total charging hours

I assume high/low byte total charging hours should be a 32bit int.

Done.


Do not redeploy external DNS record for shoot deletion

How to categorize this PR?

/area usability ops-productivity
/kind bug
/priority normal
What this PR does / why we need it:
The external DNS record is only used in the kubeconfig handed out to the end-user. Gardener itself and all system components use the internal DNS record (or in-cluster communication).
Hence, it's not necessary the redeploy the external DNS record.
Which issue(s) this PR fixes:
Fixes #3159
Special notes for your reviewer:
/cc @mvladev
Release note:

An issue has been fixed that can cause `Shoot`s from being stuck in deletion due to invalid `.spec.dns` configuration.

/lgtm


Shape is invalid for input size

Hi everyone I'm facing with this problem when I try to run train_net.py:

What is testr.num_ctrl_points? why it is 16?
I hope to get some suggestions. Thank you a lot.

Please carefully follow the guidelines and don't mix the Bezier and polygonal annotations.
We use 8 control points for Bezier and 16 for polygons, and the number is fixed, as mentioned in
the main paper.


Update bug template with Pylance info

For # N/A

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[x] Title summarizes what is changing.

LGTM!


Refine README for developer; Remove support for py37, py2k

close https://github.com/pingcap/sqlalchemy-tidb/issues/23

The README is not friendly for the developer on sqlalchemy-tidb. Refine the README, Makefile and requirements.
Remove code support for py2k and py37 that reach EOL: https://www.python.org/downloads/release/python-370/
Update requirements.py to make it works well with tests on latest version of sqlalchemy-1.4.x

/cc @wd0517 @hawkingrei


Enhancement Request: Automatic blueprint routes for binary data

Sails version: all
Node version: all
NPM version: all
Operating system: all

Hello, started recently working in sails.js and I really enjoy it. I have an enhancement request that I think make sense for binary data. Consider the following model:
module.exports = {
    attributes: {
        username: { type: "string", required: true, size: 32, unique: true },
        email: { type: "string", required: true, size: 64 },
        password: { type: "string", required: true, size: 32 },
        avatar: { type: "binary" },
        toJSON: function() { return _.omit(this.toObject(), ["password"]); }
    }
};

When I want to post data to my avatar field, I either have to do it via a contrived JSON object (I would not know how to put binary data there) or build my own controller (which is what I am doing).
I think that the blueprints should offer an additional route for binary fields such that I can GET and POST binary data. For GET:
curl -X GET http://localhost:1337/user/1/photo

There is the issue that the model does not know the mime type for photo, so it would have to be served with application/octet-stream. If I want to upload a picture, then:
curl  -X POST -H "image/jpeg" --data-binary @"avatar.jpg" http://localhost:1337/user/1/photo

That way I can get endpoints in my rest API right away without fiddling with body parsers and such. I am still struggling. And while I am at it, the binary data type documentation lacks details in the web.
I know I can store my images in S3 (or somewhere else where it makes more sense). But for completion sake, if sails provides binary data type, it could provide these endpoints.
Thanks!
Let me know if I can help.

ok, fixed.

@acrodrig Thanks for using Sails--glad you're enjoying it so far!
The purpose of that issue template is to make sure that this forum is restricted to reporting bugs in the Sails core, so we can get those triaged and fixed ASAP.  I don't want to nag, but you just checked a box that said:

I am experiencing a concrete technical issue with Sails (ideas and feature proposals should follow the guide for proposing features and enhancements (http://bit.ly/sails-feature-guide), which involves making a pull request).

We welcome new ideas to enhance the framework, and you should definitely follow the guide for contributing new features if you think this would be a good fit.  That way it can be discussed and iterated upon outside of the bug-reporting forum.  Thanks for understanding!

ok, thanks.


authors import from orcid - accept tailing and heading spaces

Currently, orcid provided by the user should be exactly the same as the imported one. We need to accept the oricd with a space before or after it, so that copying and pasting are easier.
screen-capture (10).webm

Please test in dev


Allow user to specify region when using bref init

When I use vendor/bin/bref init, I'll get a template with us-east-1 region by default.
It was quite difficult for me to find out I could modify it in the Layers string in template.yaml.
Maybe Bref should give an opportunity to define it as a command option ?
Something like:
vendor/bin/bref init --region=eu-west-1
I tried to do something like that:
    if ($region !== 'us-east-1') {
        file_put_contents('template.yaml', implode('',
            array_map(function($data) use ($region) {
                return stristr($data,"                - 'arn:aws:lambda:us-east-1:209497400698:layer:php-73-fpm:1'") ? "                - 'arn:aws:lambda:".$region.":209497400698:layer:php-73-fpm:1'\n" : $data;
            }, file('template.yaml'))
        ));
    }

It works for HTTP, but would not for Console for example.
I'm not great at modifying files :stuck_out_tongue:

👍
I think it can be OK to blindly replace any us-east-1 string with the target region (it's a very specific string, I don't see a problem happening soon).
For example: str_replace('us-east-1', $region, file_get_contents(...))

But I think also the region could be asked by bref init (with the goal that bref init is a complete "assistant"), for example:
$ vendor/bin/bref init
In which AWS region do you want to deploy your application? [us-east-1]

We could even repeat the note added in #280 to encourage users to use us-east-1 for their first project.


inconsistent output of get_historical_klines (utc+?)

for example:
when I call with start_str='2021-06-14 16:50', end_str='2021-06-14 23:12', i need to add 'utc+0300' to get the correct result
but when I call with start_str='2022-02-01 22:30', end_str='2022-02-02 04:15', i need to add 'utc+0200'.
how can I implement a solution so it will return the correct result using correct GMT offset?
thanks

In my case what I do is, to pass the dates using the time from the epoch in
ms (as integers) taking into account my local time (UTC+9). Then I obtain
the output in UTC, hope it helps ;)
On Mon, Nov 21, 2022 at 6:16 nerod10 @.***> wrote:

for example:
when I call with start_str='2021-06-14 16:50', end_str='2021-06-14 23:12',
i need to add 'utc+0300' to get the correct result
but when I call with start_str='2022-02-01 22:30', end_str='2022-02-02
04:15', i need to add 'utc+0200'.
how can I implement a solution so it will return the correct result using
correct GMT offset?
thanks
—
Reply to this email directly, view it on GitHub
https://github.com/sammchardy/python-binance/issues/1270, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEB4DPXLY5ZKDP2TD5YY7Q3WJKILDANCNFSM6AAAAAASGA76QM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


hotfixing druid realtime breaking on bad input

One of our producers was sending empty messages. The java library returns this as null, this turns InputRow null and then intake crashes on a NullPointer exception.
To ensure intake can never crash, I wrapped the whole processing in a try-catch block. It's in production here for 2 weeks, fixes the issue.

@sixtus, @fjy, how do you feel about instead just skipping null messages in the kafka firehose, or counting them as unparseable?
The reason is that skipping past any errors on getSink/sink.add seems like a heavy handed way of dealing with the problem. There might be other errors that occur that we don't want to skip past.

@gianm I like that solution. Counting them as unparseable seems pretty reasonable.

I mostly thrown this up to raise awareness that it's trivial to nuke realtime intake via input data. It's not the nicest patch, but hey, production was down and my backlog is more than full atm.
While skipping the null msgs in the firehose certainly is an option, not catching all possible exceptions in the intake is just asking for the next issue to nuke realtime.
So in short: both is probably the best solution.

Hrm, fwiw, I also think this should be handled by the catch statements in the FireChief instead of inside the plumber itself.
I also agree with doing both.  We should have a big noisy catch all that screams really loudly and then also add protection from the specific issue that Hagen ran into.

Does the implementation in #1506 work for people?

I'm +1 on using the impl in #1506

I am closing this PR as it seems like it has been addressed by #1506.


Is this project alive?

I see opened important PRs
Does author support this project?

@jasonkuhrt are you or anyone else still maintaining this project?

this issue is 29 days old
seems answer is "No"

Hi, sorry for the lack of reply. I stopped working at littleBits in January and it seems that this project has been almost entirely neglected since then. If littleBits is open to migrating this project to my Github and NPM account I would be willing to try and give this project some proper attention and be more open/reactive to including other collaborators. @sch sorry to bother you but I don't know who else to ping about this. Thanks and sorry again to anyone who was inconvenienced by inactivity on this project.

If you don't get a reply, you could just fork it, and leave a comment here, saying you are continuing development in repo jasonkuhrt/xyz
I understand it might cause a bit of confusion - but better than zero maintenance

So, any recent movement on this front? This seems like the nicest popover solution for react I've seen so far.

material-ui has a much nicer popover. I would recommend using it instead and it's actively maintained.

@cjke Certainly but its not a route I would personally like to take. The npm namespace is an issue to. @tnrich Nothing. @clayne11 Thanks for linking to an alternative.

@clayne11 Hardly the same thing. This popover smartly adjusts the position and arrow, the material-ui variant is much more primitive.

The material-ui popover also adjusts it's position based on the screen and scroll. The animation is also way better than the one for react-popover.
It's a pretty close replacement and by far the best popover I've seen in React. If you have a better suggestion feel free to link to it.

@clayne11 Well, the popover stutters heavily when it repositions (Chrome 55) and it lacks the arrow pointing to element center, which wouldn't be exactly simple to hack in. I'd love an alternative tbh.

The arrow is against the Material Design spec, hence why it isn't there.
I think the only option at this point is the make a new component because unfortunately (and surprisingly!) there isn't much else out there in the React ecosystem.
To be honest, react-popover seems dead and the code isn't very good anyways. It's extremely over-complicated. A much better alternative could be made that's much easier to maintain.

@clayne11 Seems that @jasonkuhrt would be interested in continuing this plugin, maybe that would be an option too. I'm not entirely thrilled by the React ecosystem myself, so I would pass on writing a new plugin myself.

Once again sorry for the disappointments, be it about code quality or activity. I did what I could at the time a long time ago. I'm mulling a possible react-popover2 under my account but this is still TBD. I like that there is a need I can help contribute toward so that would be my main motivation.

@clayne11

The arrow is against the Material Design spec, hence why it isn't there.

Do you have a source on that?

https://material.google.com/components/tooltips.html#tooltips-usage

@clayne11 I didn't know this existed, thanks so much!

React-Popover2 is new place, it seems!

Hey everyone, @sch gave me admin rights to this repo again a few days ago. This coincides with me getting back into JavaScript/React work after taking a long paternity leave and wild adventures into Haskell-land. I am excited to work on this project again. With a bit of luck, sweat, and help I hope to turn it into a great popover–one that you will want to use. I'll be looking for help. If you are interested the best way in is via PRs until trust is established and we formalize collaboration via membership.
My first steps will be to review the backlog, publish my priorities and feature-order roadmap (no time commitments).
Cheers everyone! CC @toddlawton would love to collaborate on this with you if you are interested!

@jasonkuhrt I'd be glad to support the project!

Unfortunately for a long time the answer was no, this project is not alive. However that's all changed now. The undead hath cometh!

Glad to have @jasonkuhrt back on this project ! 👍

@lauterry I've been working away on an upcoming blog post detailing the layout engine. This was necessary for me to jump back in and take the project further. Its almost done. My short-term plan is still to try and make a quick release fixing low hanging fruit though.

@jasonkuhrt We, at PerfectStay.com, are relying on react-popover to display filters for flights. We are really glad that react-popover has its maintainer back !


Instruction how to use it with esbuild-runner

One cool thing about TypeScript is the ability to use it without the build step on Deno or on nodejs (using esbuild-runner). It would be very cool to be able to use gleam in a similar fashion. Can esgleam be somehow integrated into esbuild-runner?

I think that is out of the scope of this project, it only handles bundling. What you're suggesting is a new feature for the Gleam build tool to enable TypeScript support with Node in some fashion.


feat: creating mongodb chart

This PR inserts the chart creation to mongodb and refactors some semantic items.

Esse pr tem que ser aberto para a develop


Add management command to update lastseen field

This command takes the filename of the most recent log file as an argument. It keeps the name of the previous log file in a stop file, so it will read what remains of the previous log file before starting on the newest log file.

pytz... i don't think that's in the requirements file?

Hmm... I thought it was part of the standard library since it's on all of my computers but I guess not.

Okay, its been so long since we last talked about this that I forgot how this was supposed to work.  It appears that updating the file date causes it to start over.  This has to do with the symlink only changing every day right?  So we keep reading more of the file until the date changes?

Yeah, that seems to be the deal.  I'm going to get a test running... @murrown maybe prepare a PR or add to this PR the last-seen value back to the UI?

Alright, I'll add it to this pull request.


standalone lora-modulation crate

@ceekdee added you as a code maintainer to this module as well as added your bandwidth comment from #123

@ivajloip we can give @ceekdee write access? i think the way you have it setup, it lets him push branches and review PRs within his code ownership purview?

and to answer @lulf, I think it could make sense to have an organization. Let's chat somewhere about how that could work (what's the ideal end state, how to get there, etc).