Thanos component of receive got recovered from panic.

Hi Thanos developers
i got error message from pod of receive component. We adopted receive component to implement multi kubernetes cluster promethues metrics query. Totally we receive about 30 cluster promethues metrics to thanos receive so far. At first we got all of   replicas(3 replicas) pod of receive are restart  several times that i guess maybe reached the resources limitation so i scale up the limit of request cpu and memory also observed a while are back to fine(without any restarts times situation). But after few hours. One of receive pod got following error. Have anyone meet same issue. Thanks.
Promethues version: v2.40.5
Thanos version: thanosio/thanos:v0.30.1
Receive compoment arguments:
- args:
   - receive
   - --grpc-address=<IP_ADDRESS>:10901
   - --http-address=<IP_ADDRESS>:10902
   - --remote-write.address=<IP_ADDRESS>:19291
   - --receive.replication-factor=1
   - --objstore.config-file=/etc/thanos/objectstorage.yaml
   - --tsdb.path=/var/thanos/receive
    - --tsdb.retention=12h
    - --label=receive_replica="$(NAME)"
    - --label=receive="true"
    - --receive.hashrings-file=/etc/thanos/thanos-receive-hashrings.json
    - --receive.local-endpoint=$(NAME).thanos-receive.thanos.svc.cluster.local:10901

$ k get po -n thanos                                                                                [23:37:10]
NAME                            READY   STATUS    RESTARTS       AGE
thanos-compact-0                1/1     Running   0              3h42m
thanos-query-5b7854649d-56xbd   1/1     Running   0              11h
thanos-query-5b7854649d-rkhtv   1/1     Running   0              12h
thanos-query-5b7854649d-wdm78   1/1     Running   0              3h15m
thanos-receive-0                1/1     Running   0              3h14m
thanos-receive-1                1/1     Running   17 (21m ago)   8h
thanos-receive-2                1/1     Running   0              3h33m
thanos-rule-0                   1/1     Running   0              3h32m
thanos-rule-1                   1/1     Running   0              12h
thanos-store-0                  1/1     Running   0              3h31m
thanos-store-1                  1/1     Running   0              11h

# thanos receive resources requests

resources:
   limits:
       cpu: "8"
       memory: 48Gi
    requests:
       cpu: "2"
        memory: 12Gi

$ k top pod -n thanos                                                                                [23:56:49]
NAME                            CPU(cores)   MEMORY(bytes)
thanos-compact-0                44m          86Mi
thanos-query-5b7854649d-56xbd   3m           56Mi
thanos-query-5b7854649d-rkhtv   3m           56Mi
thanos-query-5b7854649d-wdm78   2m           49Mi
thanos-receive-0                1227m        21168Mi
thanos-receive-1                7715m        41556Mi
thanos-receive-2                1543m        20563Mi
thanos-rule-0                   2m           46Mi
thanos-rule-1                   2m           59Mi
thanos-store-0                  2m           314Mi
thanos-store-1                  3m           379Mi

k logs -f thanos-receive-1  -n thanos

level=error ts=2023-01-16T15:15:44.615000727Z caller=grpc.go:70 component=receive service=gRPC/server component=receive msg="recovered from panic" panic="runtime error: invalid memory address or nil pointer dereference" stack="goroutine 762 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x65\ngithub.com/thanos-io/thanos/pkg/server/grpc.New.func1({0x22909c0?, 0x4109510})\n\t/app/pkg/server/grpc/grpc.go:70 +0xda\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.WithRecoveryHandler.func1.1({0xc0008a2101?, 0xc0000a0dc0?}, {0x22909c0?, 0x4109510?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/options.go:33 +0x2d\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.recoverFrom({0x2bf4288?, 0xc00343c1e0?}, {0x22909c0?, 0x4109510?}, 0x0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:53 +0x36\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1.1()\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:27 +0x68\npanic({0x22909c0, 0x4109510})\n\t/usr/local/go/src/runtime/panic.go:884 +0x212\ngithub.com/thanos-io/thanos/pkg/store.(*TSDBStore).LabelSet(0xc0087e0210?)\n\t/app/pkg/store/tsdb.go:104 +0x18\ngithub.com/thanos-io/thanos/pkg/receive.(*localClient).LabelSets(0x0?)\n\t/app/pkg/receive/multitsdb.go:109 +0x2f\ngithub.com/thanos-io/thanos/pkg/store.(*ProxyStore).LabelSet(0xc0001df440)\n\t/app/pkg/store/proxy.go:196 +0x112\nmain.runReceive.func3()\n\t/app/cmd/thanos/receive.go:323 +0x1d\ngithub.com/thanos-io/thanos/pkg/info.(*InfoServer).Info(0xc00028f9a0, {0x26b4c41?, 0x2184f60?}, 0xc0087e01f0?)\n\t/app/pkg/info/info.go:174 +0x26\ngithub.com/thanos-io/thanos/pkg/info/infopb._Info_Info_Handler.func1({0x2bf4288, 0xc00343c3c0}, {0x2579f20?, 0x417d880})\n\t/app/pkg/info/infopb/rpc.pb.go:460 +0x78\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf4288, 0xc00343c3c0}, {0x2579f20, 0x417d880}, 0x14ee6885b?, 0xc003438138)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf4288?, 0xc00343c3c0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf4288, 0xc00343c360}, {0x2579f20, 0x417d880}, 0x22f5640?, 0xc004524120)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/thanos-io/thanos/pkg/tracing.UnaryServerInterceptor.func1({0x2bf4288?, 0xc00343c2a0?}, {0x2579f20, 0x417d880}, 0x0?, 0xffffffffffffffff?)\n\t/app/pkg/tracing/grpc.go:30 +0x88\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf4288?, 0xc00343c2a0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf4288, 0xc00343c1e0}, {0x2579f20, 0x417d880}, 0x0?, 0xc004524140)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf4288?, 0xc00343c1e0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-prometheus.(*ServerMetrics).UnaryServerInterceptor.func1({0x2bf4288, 0xc00343c1e0}, {0x2579f20, 0x417d880}, 0x7fbd66a1a5c0?, 0xc004524160)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0/server_metrics.go:107 +0x87\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf4288?, 0xc00343c1e0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1({0x2bf4288?, 0xc00343c1e0?}, {0x2579f20?, 0x417d880?}, 0x7fbb99f503e8?, 0xc004524100?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:31 +0xa7\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf4288?, 0xc00343c1e0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1({0x2bf4288, 0xc00343c1e0}, {0x2579f20, 0x417d880}, 0x228f400?, 0x26056e0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:36 +0xbe\ngithub.com/thanos-io/thanos/pkg/info/infopb._Info_Info_Handler({0x223fee0?, 0xc00028f9a0}, {0x2bf4288, 0xc00343c1e0}, 0x26056e0?, 0xc0008308a0)\n\t/app/pkg/info/infopb/rpc.pb.go:462 +0x126\ngoogle.golang.org/grpc.(*Server).processUnaryRPC(0xc000832000, {0x2c06ba0, 0xc0021f6b60}, 0xc000967e60, 0xc000830c30, 0x410cb60, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1282 +0xccf\ngoogle.golang.org/grpc.(*Server).handleStream(0xc000832000, {0x2c06ba0, 0xc0021f6b60}, 0xc000967e60, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1619 +0xa2f\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.2()\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:921 +0x98\ncreated by google.golang.org/grpc.(*Server).serveStreams.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:919 +0x28a\n"

We are seeing the same issue on thanos v0.29.0. Thanos receive seems to restart out of nowhere. When the TSBD is loading, we also get the same stacktrace.

Looks like the panic is happening here: https://github.com/thanos-io/thanos/blob/main/pkg/store/tsdb.go#L104. I wonder if the TSDBStore can somehow be nil? 🤔

Hi @fpetkovski
Have anything possible to confirm that the TSDBstore? I think the pods controlled by statesfulset also mount with PVC for replicas(3) receiver. I dont't know why another pods of receiver work fine. Only  thanos-receive-1 hit TSDB error?

As @fpetkovski said, according to stack trace it seems like TSDBStore is nil in this case. It seems to be triggered via the info API, so I assume somehow the TSDBStore is not yet initialised when we're calling info API, but as to how exactly I need to look closer.

@matej-g  Thanks for your take care.

I've raised https://github.com/thanos-io/thanos/pull/6067 which believe should fix this.

Hi @fpetkovski
In additional. I had been update the thanos receive version to v0.30.2 currently. It seems no longer show this issue. However i got another issue msg as this level=error ts=2023-02-02T05:03:02.845106192Z caller=handler.go:544 component=receive component=receive-handler tenant=default-tenant err="context deadline exceeded" msg="internal server error" and level=warn ts=2023-02-02T05:00:42.308073375Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=157 cased one of receive pod restart several times.
Promethues version: v2.40.5
Thanos version: thanosio/thanos:v0.30.1
collected about 20-30 remote promethues instance metrics
promethues external labels is the same in every instances
global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s
  external_labels:
    prometheus: cic-system/prometheus
    prometheus_replica: prometheus-prometheus-0

k get po -n thanos

NAME                            READY   STATUS    RESTARTS        AGE
thanos-compact-0                1/1     Running   0               100m
thanos-query-7bd9bfb7cf-c5s2l   1/1     Running   0               102m
thanos-query-7bd9bfb7cf-svjlp   1/1     Running   0               97m
thanos-query-7bd9bfb7cf-z284k   1/1     Running   0               102m
thanos-receive-0                1/1     Running   0               90m
thanos-receive-1                0/1     Running   6 (4m51s ago)   96m
thanos-receive-2                1/1     Running   0               102m
thanos-rule-0                   1/1     Running   0               101m
thanos-rule-1                   1/1     Running   0               96m
thanos-store-0                  1/1     Running   0               99m
thanos-store-1                  1/1     Running   0               96m

apiVersion: v1
kind: ConfigMap
metadata:
  name: thanos-receive-hashrings
  namespace: thanos
data:
  thanos-receive-hashrings.json: |
    [
      {
        "hashring": "soft-tenants",
        "endpoints":
        [
            "thanos-receive-0.thanos-receive.thanos.svc.cluster.local:10901",
            "thanos-receive-1.thanos-receive.thanos.svc.cluster.local:10901",
            "thanos-receive-2.thanos-receive.thanos.svc.cluster.local:10901"
        ]
      }
    ]
---

I don't think out of order samples should lead to restarts. Can you post the logs of:

kubectl describe pod thanos-receive-1
kubectl logs --previous thanos-receive-1

Hi @fpetkovski
i run command of kubectl logs --previous thanos-receive-1 -n thanos got the detailed as following.
level=error ts=2023-02-02T09:19:10.337875555Z caller=grpc.go:70 component=receive service=gRPC/server component=receive msg="recovered from panic" panic="runtime error: invalid memory address or nil pointer dereference" stack="goroutine 127 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x65\ngithub.com/thanos-io/thanos/pkg/server/grpc.New.func1({0x22909c0?, 0x4109510})\n\t/app/pkg/server/grpc/grpc.go:70 +0xda\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.WithRecoveryHandler.func1.1({0x0?, 0x0?}, {0x22909c0?, 0x4109510?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/options.go:33 +0x2d\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.recoverFrom({0x2bf41e8?, 0xc00108fe00?}, {0x22909c0?, 0x4109510?}, 0x0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:53 +0x36\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1.1()\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:27 +0x68\npanic({0x22909c0, 0x4109510})\n\t/usr/local/go/src/runtime/panic.go:884 +0x212\ngithub.com/thanos-io/thanos/pkg/store.(*TSDBStore).LabelSet(0xc0000a7710?)\n\t/app/pkg/store/tsdb.go:104 +0x18\ngithub.com/thanos-io/thanos/pkg/receive.(*localClient).LabelSets(0xc000f8f0d0?)\n\t/app/pkg/receive/multitsdb.go:109 +0x2f\ngithub.com/thanos-io/thanos/pkg/store.(*ProxyStore).LabelSet(0xc00021e3f0)\n\t/app/pkg/store/proxy.go:196 +0x112\nmain.runReceive.func3()\n\t/app/cmd/thanos/receive.go:323 +0x1d\ngithub.com/thanos-io/thanos/pkg/info.(*InfoServer).Info(0xc000de04b0, {0x26b4c38?, 0x2184f60?}, 0xc0000a76c0?)\n\t/app/pkg/info/info.go:174 +0x26\ngithub.com/thanos-io/thanos/pkg/info/infopb._Info_Info_Handler.func1({0x2bf41e8, 0xc001116000}, {0x2579f20?, 0x417d880})\n\t/app/pkg/info/infopb/rpc.pb.go:460 +0x78\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc001116000}, {0x2579f20, 0x417d880}, 0x28a5259af?, 0xc001245b00)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116000?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc00108ff80}, {0x2579f20, 0x417d880}, 0x22f5640?, 0xc0017980c0)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/thanos-io/thanos/pkg/tracing.UnaryServerInterceptor.func1({0x2bf41e8?, 0xc00108fec0?}, {0x2579f20, 0x417d880}, 0x0?, 0xffffffffffffffff?)\n\t/app/pkg/tracing/grpc.go:30 +0x88\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc00108fec0?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc00108fe00}, {0x2579f20, 0x417d880}, 0x0?, 0xc0017980e0)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc00108fe00?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-prometheus.(*ServerMetrics).UnaryServerInterceptor.func1({0x2bf41e8, 0xc00108fe00}, {0x2579f20, 0x417d880}, 0x7f7580807200?, 0xc001798100)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0/server_metrics.go:107 +0x87\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc00108fe00?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1({0x2bf41e8?, 0xc00108fe00?}, {0x2579f20?, 0x417d880?}, 0x7f758091f9c0?, 0xc0017980a0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:31 +0xa7\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc00108fe00?}, {0x2579f20?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1({0x2bf41e8, 0xc00108fe00}, {0x2579f20, 0x417d880}, 0x228f400?, 0x26056e0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:36 +0xbe\ngithub.com/thanos-io/thanos/pkg/info/infopb._Info_Info_Handler({0x223fee0?, 0xc000de04b0}, {0x2bf41e8, 0xc00108fe00}, 0x26056e0?, 0xc000dea8a0)\n\t/app/pkg/info/infopb/rpc.pb.go:462 +0x126\ngoogle.golang.org/grpc.(*Server).processUnaryRPC(0xc000df8000, {0x2c06b00, 0xc000542d00}, 0xc001be6000, 0xc000deac30, 0x410cb60, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1282 +0xccf\ngoogle.golang.org/grpc.(*Server).handleStream(0xc000df8000, {0x2c06b00, 0xc000542d00}, 0xc001be6000, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1619 +0xa2f\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.2()\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:921 +0x98\ncreated by google.golang.org/grpc.(*Server).serveStreams.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:919 +0x28a\n"
level=error ts=2023-02-02T09:19:10.339996444Z caller=grpc.go:70 component=receive service=gRPC/server component=receive msg="recovered from panic" panic="runtime error: invalid memory address or nil pointer dereference" stack="goroutine 128 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x65\ngithub.com/thanos-io/thanos/pkg/server/grpc.New.func1({0x22909c0?, 0x4109510})\n\t/app/pkg/server/grpc/grpc.go:70 +0xda\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.WithRecoveryHandler.func1.1({0x40d95f?, 0xc0000be960?}, {0x22909c0?, 0x4109510?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/options.go:33 +0x2d\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.recoverFrom({0x2bf41e8?, 0xc001116240?}, {0x22909c0?, 0x4109510?}, 0xc000f8ef40?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:53 +0x36\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1.1()\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:27 +0x68\npanic({0x22909c0, 0x4109510})\n\t/usr/local/go/src/runtime/panic.go:884 +0x212\ngithub.com/thanos-io/thanos/pkg/store.(*TSDBStore).TimeRange(0xc000f8f0e8?)\n\t/app/pkg/store/tsdb.go:117 +0x14\ngithub.com/thanos-io/thanos/pkg/receive.(*localClient).TimeRange(0x40?)\n\t/app/pkg/receive/multitsdb.go:113 +0x1b\ngithub.com/thanos-io/thanos/pkg/store.(*ProxyStore).Info(0xc00021e3f0, {0x232f1a0?, 0x2504820?}, 0x8000000000000000?)\n\t/app/pkg/store/proxy.go:152 +0x178\ngithub.com/thanos-io/thanos/pkg/store/storepb._Store_Info_Handler.func1({0x2bf41e8, 0xc001116420}, {0x257be60?, 0x417d880})\n\t/app/pkg/store/storepb/rpc.pb.go:1071 +0x78\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc001116420}, {0x257be60, 0x417d880}, 0x28a71fb4a?, 0xc001245c68)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116420?}, {0x257be60?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc0011163c0}, {0x257be60, 0x417d880}, 0x22f5640?, 0xc001798260)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/thanos-io/thanos/pkg/tracing.UnaryServerInterceptor.func1({0x2bf41e8?, 0xc001116300?}, {0x257be60, 0x417d880}, 0x0?, 0xffffffffffffffff?)\n\t/app/pkg/tracing/grpc.go:30 +0x88\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116300?}, {0x257be60?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors.UnaryServerInterceptor.func1({0x2bf41e8, 0xc001116240}, {0x257be60, 0x417d880}, 0x0?, 0xc001798280)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/server.go:22 +0x21e\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116240?}, {0x257be60?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-prometheus.(*ServerMetrics).UnaryServerInterceptor.func1({0x2bf41e8, 0xc001116240}, {0x257be60, 0x417d880}, 0x7f75808073b8?, 0xc0017982a0)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0/server_metrics.go:107 +0x87\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116240?}, {0x257be60?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery.UnaryServerInterceptor.func1({0x2bf41e8?, 0xc001116240?}, {0x257be60?, 0x417d880?}, 0x7f758091f9c0?, 0xc001798240?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/interceptors/recovery/interceptors.go:31 +0xa7\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1.1.1({0x2bf41e8?, 0xc001116240?}, {0x257be60?, 0x417d880?})\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:27 +0x3a\ngithub.com/grpc-ecosystem/go-grpc-middleware/v2.ChainUnaryServer.func1({0x2bf41e8, 0xc001116240}, {0x257be60, 0x417d880}, 0x228f400?, 0x26056e0?)\n\t/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.0-rc.2.0.20201207153454-9f6bf00c00a7/chain.go:36 +0xbe\ngithub.com/thanos-io/thanos/pkg/store/storepb._Store_Info_Handler({0x2504820?, 0xc00021a3c0}, {0x2bf41e8, 0xc001116240}, 0x26056e0?, 0xc000dea8a0)\n\t/app/pkg/store/storepb/rpc.pb.go:1073 +0x126\ngoogle.golang.org/grpc.(*Server).processUnaryRPC(0xc000df8000, {0x2c06b00, 0xc000542d00}, 0xc001be6360, 0xc000deaa80, 0x411a120, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1282 +0xccf\ngoogle.golang.org/grpc.(*Server).handleStream(0xc000df8000, {0x2c06b00, 0xc000542d00}, 0xc001be6360, 0x0)\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:1619 +0xa2f\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.2()\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:921 +0x98\ncreated by google.golang.org/grpc.(*Server).serveStreams.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.45.0/server.go:919 +0x28a\n"
level=error ts=2023-02-02T09:19:12.185489067Z caller=head.go:590 component=receive component=multi-tsdb tenant=default-tenant msg="Loading on-disk chunks failed" err="iterate on on-disk chunks: out of sequence m-mapped chunk for series ref 39677950, last chunk: [1675318174037,<PHONE_NUMBER>037], new: [1675315399046,<PHONE_NUMBER>046]"
level=info ts=2023-02-02T09:19:12.18556617Z caller=head.go:825 component=receive component=multi-tsdb tenant=default-tenant msg="Deleting mmapped chunk files"
level=info ts=2023-02-02T09:19:12.18770156Z caller=head.go:831 component=receive component=multi-tsdb tenant=default-tenant msg="Deleting mmapped chunk files"
level=info ts=2023-02-02T09:19:12.187746562Z caller=head.go:834 component=receive component=multi-tsdb tenant=default-tenant msg="Deletion of corrupted mmap chunk files failed, discarding chunk files completely" err="cannot handle error: iterate on on-disk chunks: out of sequence m-mapped chunk for series ref 39677950, last chunk: [1675318174037,<PHONE_NUMBER>037], new: [1675315399046,<PHONE_NUMBER>046]"
level=info ts=2023-02-02T09:19:12.309931207Z caller=head.go:606 component=receive component=multi-tsdb tenant=default-tenant msg="On-disk memory mappable chunks replay completed" duration=7.102967039s
level=info ts=2023-02-02T09:19:12.30998721Z caller=head.go:612 component=receive component=multi-tsdb tenant=default-tenant msg="Replaying WAL, this may take a while"
level=info ts=2023-02-02T09:22:01.66016654Z caller=head.go:648 component=receive component=multi-tsdb tenant=default-tenant msg="WAL checkpoint loaded"
level=info ts=2023-02-02T09:22:07.72185801Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3522 maxSegment=3590
level=info ts=2023-02-02T09:22:11.216360932Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3523 maxSegment=3590
level=info ts=2023-02-02T09:22:13.877105639Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3524 maxSegment=3590
level=info ts=2023-02-02T09:22:22.015376614Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3525 maxSegment=3590
level=info ts=2023-02-02T09:22:26.834855691Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3526 maxSegment=3590
level=info ts=2023-02-02T09:22:28.585117878Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3527 maxSegment=3590
level=info ts=2023-02-02T09:22:29.193702156Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3528 maxSegment=3590
level=info ts=2023-02-02T09:22:30.095454818Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3529 maxSegment=3590
level=info ts=2023-02-02T09:22:30.096456445Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3530 maxSegment=3590
level=info ts=2023-02-02T09:22:30.10455015Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3531 maxSegment=3590
level=info ts=2023-02-02T09:22:30.105468483Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3532 maxSegment=3590
level=info ts=2023-02-02T09:22:30.533545184Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3533 maxSegment=3590
level=info ts=2023-02-02T09:22:30.533937748Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3534 maxSegment=3590
level=info ts=2023-02-02T09:22:33.948233395Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3535 maxSegment=3590
level=info ts=2023-02-02T09:22:33.948643762Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3536 maxSegment=3590
level=info ts=2023-02-02T09:22:37.037965441Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3537 maxSegment=3590
level=info ts=2023-02-02T09:22:37.04769483Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3538 maxSegment=3590
level=info ts=2023-02-02T09:22:40.292334983Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3539 maxSegment=3590
level=info ts=2023-02-02T09:22:40.292763442Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3540 maxSegment=3590
level=info ts=2023-02-02T09:22:43.032166933Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3541 maxSegment=3590
level=info ts=2023-02-02T09:22:43.04132819Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3542 maxSegment=3590
level=info ts=2023-02-02T09:22:46.536321596Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3543 maxSegment=3590
level=info ts=2023-02-02T09:22:46.537366196Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3544 maxSegment=3590
level=info ts=2023-02-02T09:22:47.914108191Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3545 maxSegment=3590
level=info ts=2023-02-02T09:22:47.914509629Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3546 maxSegment=3590
level=info ts=2023-02-02T09:22:51.690457624Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3547 maxSegment=3590
level=info ts=2023-02-02T09:22:51.691488185Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3548 maxSegment=3590
level=info ts=2023-02-02T09:22:51.97368926Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3549 maxSegment=3590
level=info ts=2023-02-02T09:22:51.974045616Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3550 maxSegment=3590
level=info ts=2023-02-02T09:22:51.97994664Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3551 maxSegment=3590
level=info ts=2023-02-02T09:22:51.981090019Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3552 maxSegment=3590
level=warn ts=2023-02-02T09:23:36.107749025Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=11 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:23:36.107843038Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3553 maxSegment=3590
level=warn ts=2023-02-02T09:24:12.401880958Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=1 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:24:12.401961273Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3554 maxSegment=3590
level=info ts=2023-02-02T09:24:42.489455618Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3555 maxSegment=3590
level=warn ts=2023-02-02T09:25:09.996509564Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=78 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:25:09.996584776Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3556 maxSegment=3590
level=warn ts=2023-02-02T09:25:32.902585514Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=1381 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:25:32.902654321Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3557 maxSegment=3590
level=warn ts=2023-02-02T09:26:42.474967685Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=30 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:26:42.475058296Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3558 maxSegment=3590
level=info ts=2023-02-02T09:27:09.43432155Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3559 maxSegment=3590
level=info ts=2023-02-02T09:27:35.071131027Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3560 maxSegment=3590
level=info ts=2023-02-02T09:27:56.405102302Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3561 maxSegment=3590
level=info ts=2023-02-02T09:28:17.611360868Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3562 maxSegment=3590
level=info ts=2023-02-02T09:28:45.511098239Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3563 maxSegment=3590
level=info ts=2023-02-02T09:29:35.119612968Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3564 maxSegment=3590
level=info ts=2023-02-02T09:30:29.174803666Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3565 maxSegment=3590
level=info ts=2023-02-02T09:30:52.81131704Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3566 maxSegment=3590
level=info ts=2023-02-02T09:31:22.500840331Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3567 maxSegment=3590
level=info ts=2023-02-02T09:31:53.336546444Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3568 maxSegment=3590
level=info ts=2023-02-02T09:32:24.706632278Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3569 maxSegment=3590
level=info ts=2023-02-02T09:33:23.240959703Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3570 maxSegment=3590
level=info ts=2023-02-02T09:34:07.440000122Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3571 maxSegment=3590
level=info ts=2023-02-02T09:34:31.680250827Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3572 maxSegment=3590
level=info ts=2023-02-02T09:35:03.592994435Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3573 maxSegment=3590
level=info ts=2023-02-02T09:35:13.435226522Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3574 maxSegment=3590
level=info ts=2023-02-02T09:35:36.443986132Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3575 maxSegment=3590
level=info ts=2023-02-02T09:35:40.896672984Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3576 maxSegment=3590
level=warn ts=2023-02-02T09:35:51.338969115Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=2118 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:35:51.339059919Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3577 maxSegment=3590
level=info ts=2023-02-02T09:35:51.425255012Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3578 maxSegment=3590
level=info ts=2023-02-02T09:36:47.653356145Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3579 maxSegment=3590
level=info ts=2023-02-02T09:37:38.919866978Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3580 maxSegment=3590
level=info ts=2023-02-02T09:38:09.746025186Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3581 maxSegment=3590
level=info ts=2023-02-02T09:38:39.013375223Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3582 maxSegment=3590
level=info ts=2023-02-02T09:39:05.50310057Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3583 maxSegment=3590
level=info ts=2023-02-02T09:39:31.929050297Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3584 maxSegment=3590
level=info ts=2023-02-02T09:40:27.430730888Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3585 maxSegment=3590
level=info ts=2023-02-02T09:41:13.521228684Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3586 maxSegment=3590
level=info ts=2023-02-02T09:41:37.507649803Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3587 maxSegment=3590
level=info ts=2023-02-02T09:41:53.213302941Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3588 maxSegment=3590
level=warn ts=2023-02-02T09:42:08.895343813Z caller=head_wal.go:394 component=receive component=multi-tsdb tenant=default-tenant msg="Unknown series references" samples=2 exemplars=0 histograms=0 metadata=0
level=info ts=2023-02-02T09:42:08.895431227Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3589 maxSegment=3590
level=info ts=2023-02-02T09:42:08.895974615Z caller=head.go:683 component=receive component=multi-tsdb tenant=default-tenant msg="WAL segment loaded" segment=3590 maxSegment=3590
level=info ts=2023-02-02T09:42:08.896000919Z caller=head.go:720 component=receive component=multi-tsdb tenant=default-tenant msg="WAL replay completed" checkpoint_replay_duration=2m49.350229941s wal_replay_duration=20m7.235769968s wbl_replay_duration=400ns total_replay_duration=23m3.689039951s
level=info ts=2023-02-02T09:42:54.064017452Z caller=multitsdb.go:534 component=receive component=multi-tsdb tenant=default-tenant msg="TSDB is now ready"
level=info ts=2023-02-02T09:42:54.097964256Z caller=intrumentation.go:56 component=receive msg="changing probe status" status=ready
level=info ts=2023-02-02T09:42:54.098002562Z caller=receive.go:616 component=receive msg="storage started, and server is ready to receive requests"
level=warn ts=2023-02-02T09:43:08.741780794Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=157
level=warn ts=2023-02-02T09:43:08.744918326Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=187
level=warn ts=2023-02-02T09:43:08.816567704Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=175
level=warn ts=2023-02-02T09:43:08.826098412Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=146
level=warn ts=2023-02-02T09:43:08.859955193Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=180
level=warn ts=2023-02-02T09:43:08.873848262Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=119
level=warn ts=2023-02-02T09:43:08.92800449Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=159
level=warn ts=2023-02-02T09:43:08.932687885Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=156
level=warn ts=2023-02-02T09:43:08.996877874Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=182
level=warn ts=2023-02-02T09:43:09.042821733Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=165
level=warn ts=2023-02-02T09:43:09.044143473Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=157
level=warn ts=2023-02-02T09:43:09.097278392Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=153
level=warn ts=2023-02-02T09:43:09.134065983Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=167
level=warn ts=2023-02-02T09:43:09.165086464Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=155
level=warn ts=2023-02-02T09:43:09.220763252Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=177
level=warn ts=2023-02-02T09:43:09.241381533Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=69
level=warn ts=2023-02-02T09:43:09.251690223Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=171
level=warn ts=2023-02-02T09:43:09.258125504Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=110
level=warn ts=2023-02-02T09:43:09.263312952Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=170
level=warn ts=2023-02-02T09:43:09.280965719Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=167
level=warn ts=2023-02-02T09:43:09.287243783Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=147
level=warn ts=2023-02-02T09:43:09.31539176Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=165
level=warn ts=2023-02-02T09:43:09.315777501Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=170
level=warn ts=2023-02-02T09:43:09.318375376Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=185
level=warn ts=2023-02-02T09:43:09.334437175Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=164
level=warn ts=2023-02-02T09:43:09.338388293Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=175
level=warn ts=2023-02-02T09:43:09.340381303Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=166
level=warn ts=2023-02-02T09:43:09.380420538Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=81
level=warn ts=2023-02-02T09:43:09.400156625Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=164
level=warn ts=2023-02-02T09:43:09.409360099Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=78
level=warn ts=2023-02-02T09:43:09.415381335Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=170
level=warn ts=2023-02-02T09:43:09.43509312Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=171
level=warn ts=2023-02-02T09:43:09.437115834Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=188
level=warn ts=2023-02-02T09:43:09.473561589Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=83
level=warn ts=2023-02-02T09:43:09.475029144Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=81
level=warn ts=2023-02-02T09:43:09.491458582Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=166
level=warn ts=2023-02-02T09:43:09.494708425Z caller=writer.go:188 component=receive component=receive-writer tenant=default-tenant msg="Error on ingesting samples that are too old or are too far into the future" numDropped=157

Could you also post the logs of the describe command?

Sure. However i had been increased cpu/memory requests earlier. Previously error err="context deadline exceeded" msg="internal server error seems cannot duplicated. Currently describe command detailed as following.
updated cpu limit from 8 to 16 as well as memory limit from 48 to 56
k describe pod thanos-receive-1 -n thanos

Name:         thanos-receive-1
Namespace:    thanos
Priority:     0
Node:         shoot--rm--rm-dev-big-nodes-z2-66bd4-rskhs/<IP_ADDRESS>
Start Time:   Thu, 02 Feb 2023 17:03:52 +0800
Labels:       controller-revision-hash=thanos-receive-77567dddd4
              kubernetes.io/name=thanos-receive
              statefulset.kubernetes.io/pod-name=thanos-receive-1
              thanos-store-api=true
Annotations:  cni.projectcalico.org/containerID: 2f4128f7d732f736447002600b9e44e038cffcc29edfd2c8b30b1891f9e1fb56
              cni.projectcalico.org/podIP: <IP_ADDRESS>/32
              cni.projectcalico.org/podIPs: <IP_ADDRESS>/32
              kubernetes.io/psp: gardener.privileged
              policies.kyverno.io/last-applied-patches: image-pull-secret-add.image-pull-secret-operation.kyverno.io: added /spec/imagePullSecrets/0
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  StatefulSet/thanos-receive
Containers:
  thanos-receive:
    Container ID:  containerd://d63431cf0ae2a99dcee8e73ca929cf293f4992667ac2becf11264472c8511eed
    Image:         thanosio/thanos:v0.30.2
    Image ID:      docker.io/thanosio/thanos@sha256:6b97f63c716781c487da88750850cf5a4e0a1c23af32764e97faefc1383432b1
    Ports:         10901/TCP, 10902/TCP, 19291/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP
    Args:
      receive
      --grpc-address=<IP_ADDRESS>:10901
      --http-address=<IP_ADDRESS>:10902
      --remote-write.address=<IP_ADDRESS>:19291
      --receive.replication-factor=1
      --objstore.config-file=/etc/thanos/objectstorage.yaml
      --tsdb.path=/var/thanos/receive
      --tsdb.retention=12h
      --receive-forward-timeout=120s
      --label=receive_replica="$(NAME)"
      --label=receive="true"
      --receive.hashrings-file=/etc/thanos/thanos-receive-hashrings.json
      --receive.local-endpoint=$(NAME).thanos-receive.thanos.svc.cluster.local:10901
    State:          Running
      Started:      Thu, 02 Feb 2023 17:49:01 +0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Thu, 02 Feb 2023 17:18:59 +0800
      Finished:     Thu, 02 Feb 2023 17:48:46 +0800
    Ready:          True
    Restart Count:  2
    Limits:
      cpu:     16
      memory:  56Gi
    Requests:
      cpu:      2
      memory:   12Gi
    Liveness:   http-get http://:10902/-/healthy delay=0s timeout=1s period=30s #success=1 #failure=4
    Readiness:  http-get http://:10902/-/ready delay=10s timeout=1s period=30s #success=1 #failure=3
    Environment:
      NAME:                     thanos-receive-1 (v1:metadata.name)
      KUBERNETES_SERVICE_HOST:  api.rm-dev.rm.internal.live.k8s.ondemand.com
    Mounts:
      /etc/thanos/objectstorage.yaml from thanos-objectstorage (rw,path="objectstorage.yaml")
      /etc/thanos/thanos-receive-hashrings.json from thanos-receive-hashrings (rw,path="thanos-receive-hashrings.json")
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rmxcc (ro)
      /var/thanos/receive from data (rw)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-thanos-receive-1
    ReadOnly:   false
  thanos-receive-hashrings:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      thanos-receive-hashrings
    Optional:  false
  thanos-objectstorage:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  thanos-objectstorage
    Optional:    false
  kube-api-access-rmxcc:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

@fpetkovski Not OP, we are facing the same problem (the panic due to nil store LabelSet) that doesn't go away even with changes in #6067.
This is happening on one particular environment (also happens to have the data folder in a PV like the original poster). We are on 0.30.2 with the changes in #6067 cherry-picked. Trying to isolate/figure out a minimal reproducible example, but wanted to check with you - if you can think of a reason why this bug would still occur.

You might be hitting https://github.com/thanos-io/thanos/issues/6190


Actively enable std modules and/or builtin functions

What do you think of allowing active enabling of std modules and builtin functions instead of disabling them one by one. That is, in addition to DisableBuiltinFunction and DisableStdModule also include EnableBuiltinFunction, EnableStdModule, DisableAllBuiltins and DisableAllStdModules.
This leaves current usage as is, but also allows disabling all builtins and std modules so that they can be enabled one by one. This is the more secure option that avoids the scenario where an update of tengo automatically updates any possible builtins or modules that need to be locked out in the code the embeds tengo.

What about adding SetBuiltinFunctions(map[string]*objects.BuiltinFunction) and SetStdModules(map[string]*objects.ImmutableMap) that replaces all builtins and modules? If we do that, another change we will need is to have VM to take the built functions as a parameter like builtinModules. Btw, I was using stdmodules and builtin modules in different code but they're the same, which can be confusing. So we may want to fix that too. I'm more inclined towards builtin modules over stdmodules, but, what do you think?

SetBuiltinFunctions and SetStdModules works. It's also consistent with SetUserModuleLoader.
I'm partial towards builtin over std as well and making them consistent is a good idea.


Allow searching new user in chat finder page

Details

Allow searching new user in chat finder page
Fixed Issues

$ https://github.com/Expensify/App/issues/40731
PROPOSAL: https://github.com/Expensify/App/issues/40731#issuecomment-2072988220
Tests

Click search icon in LHN to open the finder page
Type any email address of a new user who does not have expensify account
Verify that an option is appeared
Click on this option and verify that a new report is created and we're able to start chat with this user

[x] Verify that no errors appear in the JS console

Offline tests

Same as above
QA Steps

Click search icon in LHN to open the finder page
Type any email address of a new user who does not have expensify account
Verify that an option is appeared
Click on this option and verify that a new report is created and we're able to start chat with this user

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome
https://github.com/Expensify/App/assets/161821005/2d06abac-4596-4006-9e73-2d084e574a67

iOS: Native
https://github.com/Expensify/App/assets/161821005/457d80c9-cfc5-412b-970d-4bd8c62658af

iOS: mWeb Safari
https://github.com/Expensify/App/assets/161821005/08a1f731-d863-4288-85e4-b7a52e8aafbe

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/161821005/7695098c-0bca-4fec-8e4f-45062e4b3bdd

MacOS: Desktop
https://github.com/Expensify/App/assets/161821005/8601e04c-4350-4ae4-ac62-5207c08876bf

Over to you @DylanDylann

This PR is my son, I will take it

@nkdengineer lint error

@DylanDylann Fixed.

@nkdengineer Oh my bad. Everything looks good. @MonilBhavsar All yours

@nkdengineer I give some comments, Let's address it

@DylanDylann Updated, please help to check again.

@DylanDylann Please help to check again when you have time.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/marcaaron in version: 1.4.71-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add files via upload

@danielkin17 This domain does not belong to a university, nor to a college. I have to close the request without merging. Please ensure that you are familiar with this repository rules located at the bottom of this page before submitting a new request.


Fix links

Fixes https://github.com/MicrosoftDocs/feedback/issues/3229.

@gewarren : Thanks for your contribution! The author(s) have been notified to review your proposed change.


v4.0.0-RC1 Availability

Thanks for running this project. Interested to try it out with CE3 and was wondering if v4.0.0-RC1 was available prebuilt anywhere? I didn't see it on maven.

hello can you give me more details, because i can see it was published to sonatype

https://mvnrepository.com/artifact/io.laserdisc/fs2-aws-kinesis_2.13/4.0.0-RC1

Oh I was looking at the wrong spot 🤦 https://search.maven.org/artifact/io.laserdisc/fs2-aws_2.13. Ignore me.


[wxWidgets] build failure on github actions (Windows-lastest)

Host Environment

OS: Windows-lastest as in github actions
Compiler: Mingw-w64 11.2.0
all information about the OS and pre-installed software should be listed here : https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md

To Reproduce
Steps to reproduce the behavior:
The command issued in my workflow is vcpkg install wxwidgets:x64-mingw-static.
You can find the full workflow and the command outputs here : https://github.com/Stovent/CeDImu/actions/runs/3063817118/jobs/4946307979
Failure logs
[1/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-gcc.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=1 -DwxUSE_GUI=0 -IC:/vcpkg/installed/x64-mingw-static/debug/../include -IC:/vcpkg/installed/x64-mingw-static/include -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -MD -MT libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/extended.c.obj -MF libs\base\CMakeFiles\wxbase.dir\__\__\__\__\src\common\extended.c.obj.d -o libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/extended.c.obj -c C:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/src/common/extended.c
cc1.exe: warning: command-line option '-Wno-ctor-dtor-privacy' is valid for C++/ObjC++ but not for C
cc1.exe: warning: command-line option '-Woverloaded-virtual' is valid for C++/ObjC++ but not for C
[2/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=0 -DwxUSE_GUI=1 -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -MD -MT libs/adv/CMakeFiles/wxadv.dir/__/__/__/__/src/common/dummy.cpp.obj -MF libs\adv\CMakeFiles\wxadv.dir\__\__\__\__\src\common\dummy.cpp.obj.d -o libs/adv/CMakeFiles/wxadv.dir/__/__/__/__/src/common/dummy.cpp.obj -c C:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/src/common/dummy.cpp
[3/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=1 -DwxUSE_GUI=0 -IC:/vcpkg/installed/x64-mingw-static/debug/../include -IC:/vcpkg/installed/x64-mingw-static/include -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -Winvalid-pch -x c++-header -include C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx -MD -MT libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx.gch -MF libs\base\CMakeFiles\wxbase.dir\cmake_pch.hxx.gch.d -o libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx.gch -c C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx.cxx
[4/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=1 -DwxUSE_GUI=0 -IC:/vcpkg/installed/x64-mingw-static/debug/../include -IC:/vcpkg/installed/x64-mingw-static/include -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -Winvalid-pch -include C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx -MD -MT libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/appbase.cpp.obj -MF libs\base\CMakeFiles\wxbase.dir\__\__\__\__\src\common\appbase.cpp.obj.d -o libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/appbase.cpp.obj -c C:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/src/common/appbase.cpp
FAILED: libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/appbase.cpp.obj
C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=1 -DwxUSE_GUI=0 -IC:/vcpkg/installed/x64-mingw-static/debug/../include -IC:/vcpkg/installed/x64-mingw-static/include -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -Winvalid-pch -include C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/base/CMakeFiles/wxbase.dir/cmake_pch.hxx -MD -MT libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/appbase.cpp.obj -MF libs\base\CMakeFiles\wxbase.dir\__\__\__\__\src\common\appbase.cpp.obj.d -o libs/base/CMakeFiles/wxbase.dir/__/__/__/__/src/common/appbase.cpp.obj -c C:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/src/common/appbase.cpp

[5/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=0 -DwxUSE_GUI=1 -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -Winvalid-pch -x c++-header -include C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/aui/CMakeFiles/wxaui.dir/cmake_pch.hxx -MD -MT libs/aui/CMakeFiles/wxaui.dir/cmake_pch.hxx.gch -MF libs\aui\CMakeFiles\wxaui.dir\cmake_pch.hxx.gch.d -o libs/aui/CMakeFiles/wxaui.dir/cmake_pch.hxx.gch -c C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/aui/CMakeFiles/wxaui.dir/cmake_pch.hxx.cxx
[6/815] C:\ProgramData\chocolatey\bin\x86_64-w64-mingw32-g++.exe -DUNICODE -DWXBUILDING -DWX_PRECOMP -D_UNICODE -D__WXMSW__ -DwxUSE_BASE=0 -DwxUSE_GUI=1 -IC:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/lib/mswud -IC:/vcpkg/buildtrees/wxwidgets/src/v3.2.0-8a0adfb316.clean/include -g -Wall -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wundef -Wunused-parameter -pthread -Winvalid-pch -x c++-header -include C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/html/CMakeFiles/wxhtml.dir/cmake_pch.hxx -MD -MT libs/html/CMakeFiles/wxhtml.dir/cmake_pch.hxx.gch -MF libs\html\CMakeFiles\wxhtml.dir\cmake_pch.hxx.gch.d -o libs/html/CMakeFiles/wxhtml.dir/cmake_pch.hxx.gch -c C:/vcpkg/buildtrees/wxwidgets/x64-mingw-static-dbg/libs/html/CMakeFiles/wxhtml.dir/cmake_pch.hxx.cxx
ninja: build stopped: subcommand failed.

install-x64-mingw-static-dbg-out.log
If you need additional information let me know, I can modify and run other workflows to help diagnose the problem.

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.

The issue is still here, I've run a new workflow to confirm : https://github.com/Stovent/CeDImu/actions/runs/4580589282
Unfortunately the new log file doesn't contain more information and I can't reproduce it locally so I don't know how this could be troubleshooted.
Also I cannot reopen the issue myself

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.

For reference this is now fixed when installing wxWidgets 3.2.3 (don't know what fixed it though) : https://github.com/Stovent/CeDImu/actions/runs/7001405993/job/19043459349


Search: clicking on search view icon no longer puts focus into input box

Steps to Reproduce:

click on "Search" icon in activity bar

=> 🐛 focus is not put into the input box anymore

Hm, I think I can reproduce for any viewlet. @sbatten @isidorn maybe due to some recent refactorings?

Looks like broken due to refactoring.

@sbatten pushed a fix for this what seemed rational to me..

thanks @isidorn LGTM, sorry about that


Question: combine SimpleObject and Object behavior for GraphQL type

Would it be useful to have ability to implement GraphQL type like that:
#[SimpleObject]
#[derive(Clone)]
pub struct SomeType {
    id: ID,
    test_field: CustomDecimal,
    test_field_2: String
}

#[Object]
impl SomeType {
    async fn test_field_2(&self) -> &str {
        ""
    }
}

?
This would allow to reduce boilerplate code needed for accessors of first two fields.

Duplicate https://github.com/async-graphql/async-graphql/issues/35


Redundant language

Chapter 5 states:

This section defines the BRS-I mandatory and optional UEFI
requirements on top of [9], and is optional and recommended for
BRS-B. Additional non-normative guidance may be found in the
Firmware Implementation Guidance section.

This is redundant with Chapter 2.
Similar language is in Chapter 6 and 7.

Well, apparently it wasn't redundant enough as per #128.
Chapter 2 is a mess.


Readme in portuguese

Added a translated, Readme in Portuguese

This PR aims to solve issue #9

Sorry, I thought I commited the translation, but I saw it wasn't. Now I think it's ok and can be helpful for issue #9


Code Complete

Widely considered one of the best practical guides to programming, Steve McConnell's original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices--and hundreds of new code samples--illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking--and help you build the highest quality code.

I'm reading this book, it's cool, if anyone needs it I will share the Chinese version and the English version


any clue about this issue?

shailendrapathak@dd-D32:~/Desktop$ node parsedocx.js
/home/shailendrapathak/node_modules/xml2js/lib/xml2js.js:269
if (str.toString().trim() === '') {
^
TypeError: Cannot call method 'toString' of undefined
at Parser.exports.Parser.Parser.parseString (/home/shailendrapathak/node_modules/xml2js/lib/xml2js.js:269:15)
at Parser.parseString (/home/shailendrapathak/node_modules/xml2js/lib/xml2js.js:6:61)
at processMainDocument (/home/shailendrapathak/Desktop/parsedocx.js:65:9)
at Object. (/home/shailendrapathak/Desktop/parsedocx.js:57:1)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)

I encountered this problem as well. I was passing an undefined.
It would be prudent to not 'crash' node but check for it in the library and pass something in the err of the callback.
It was confusing that your call was completing but not doing what was expected of it.


⚠ Guya.moe Proxied has degraded performance

In efcfefd, Guya.moe Proxied (https://ice.guya.moe/) experienced degraded performance:

HTTP code: 200
Response time: 11957 ms

Resolved: Guya.moe Proxied performance has improved in 29d21b0 after 5 minutes.


CASMTRIAGE-7348 add script and documentation to add OSDs to removable disks

Description
On Gamora, it was observed that each storage node only had 2 osds. Storage nodes are expected to have 4+ OSDs. On Gamora, the problem was that 4 disks on each storage node were "removable" and were not discoverable by the Ceph Orchestrator. In order to create OSDs on removable disks, I have added a script as well as troubleshooting documentation.
This script has been tested on Gamora.

Checklist

[x] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[x] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

One thing I noticed on the system where this script was run is that the REWEIGHT value for all of the new OSDs is set to 1.000 rather than .800 (or .799).   Do we need to adjust those values down to get ceph some space to shuffle data around?


Remove Nth Node From End of List

How to remove Nth number node from the end of a linked list when the head of the linked list is given.

Remove Nth  node from end of a list


Why is there a <internal> namespace for modules?

Search terms

modules, monorepo, internal, , namespace
Question
Why does my modules have a <internal> namespace?? It seems unnecessary because it only has docs for stuff already documented in other modules.

typedoc.json:
{
	"$schema": "https://typedoc.org/schema.json",
	"name": "Guilded.TS",
	"entryPointStrategy": "packages",
	"entryPoints": ["packages/*"],
	"cleanOutputDir": true,
	"lightHighlightTheme": "github-light",
	"darkHighlightTheme": "github-dark",
	"excludeExternals": true,
	"excludeInternal": true,
	"excludePrivate": true,
	"media": "media",
	"out": "docs",
	"readme": "packages/guilded.ts/README.md",
	"tsconfig": "tsconfig.json",
	"hideGenerator": true,
	"cname": "guildedts.js.org"
}

Repo code if needed: https://github.com/guildedts/guilded.ts

#1835 - cross package references aren't supported yet.


Cache value when iterating over IndexedTableColumnValueSelector

The check for isNull and getting a primitive for the IndexedTableColumnValueSelector is almost identical.
In several places throughout the code, selectors explicitly check if a value is null before getting the value. So the IndexedTableColumnValueSelector does double the work here. This change makes it so that the value is cached across calls.
In local performance tests, the improvement on small segments (~ 100K) was within the margin of error on my laptop.
Flamegraphs collected show that less time is being spent in getting the value from the selector,
however the selector still needs to convert the raw object to the primitive type. This is where
the selector spends most of it's time now. The primitive / object conversion appears to be a problem across other parts of the query interface as well.
Trying to add support for primitives across this interface seemed like too large of a change to take on at this point in time.

Not sure if this change is worth it as is, since we're still within the margin of error, so I can't prove it's better :(

Benchmark	(query)	(vectorize)	Mode	Cnt	Score (master)		Error(master)	Units	Score (caching)	Error(caching)	Delta
JoinBenchmark.querySql	count(*), join 3 tables	FALSE	avgt	3	54.185	±	11.824	ms/op	52.683	14.109	1.502
JoinBenchmark.querySql	group by 2 cols, calculate and order by sum, grou, join 2 tables on id	FALSE	avgt	3	116.448	±	8.003	ms/op	122.332	23.478	-5.884
JoinBenchmark.querySql	group by 1 col, calculate and order by sum, grou, join 2 tables on id	FALSE	avgt	3	47.609	±	11.332	ms/op	49.626	6.763	-2.017
JoinBenchmark.querySql	group by, filter on high cardinality column , join 2 tables	FALSE	avgt	3	14.491	±	3.292	ms/op	14.635	2.014	-0.144
JoinBenchmark.querySql	group by, filter on low cardinality column , join 2 tables	FALSE	avgt	3	124.18	±	94.693	ms/op	120.294	3.943	3.886
JoinBenchmark.querySql	group by, filter on low cardinality column in both tables, join 2 tables	FALSE	avgt	3	19.257	±	14.601	ms/op	19.131	2.614	0.126
JoinBenchmark.querySql	group by, filter on low and high cardinality, join 3 tables	FALSE	avgt	3	25.539	±	13.968	ms/op	24.155	2.703	1.384
JoinBenchmark.querySql	top 100 on high cardinality column, join 3 tables	FALSE	avgt	3	431.9	±	59.677	ms/op	419.277	55.198	12.623
JoinBenchmark.querySql	group by 2 columns, sum having greater than, join 2 tables	FALSE	avgt	3	227.124	±	278.733	ms/op	194.003	26.668	33.121


Support branches as versions (from setup-erlang)

While merging setup-erlang with setup-elixir I see that versions like master are supported in the latter. Should we add support for that to  rebar3-version, for example?

We are basing the rebar3 versions off of GitHub releases, not even tags, so branches don't seem like a good idea at the moment. If the need arises by use of the action we should discuss it and figure out a way to do it.


oneOf should be allowed on model properties

Something like this should be allowed:
model A {
  @oneOf
  values: string | string[];
}

Should we consider named unions ?
@oneOf
union MyNamedUnion {
  one: string,
  two: string[],
}

model A {
  values: MyNamedUnion;
}


Staff: Dashboard index summary stats visual design improvement

This is not urgent, but if someone has an eye for design and wants to tackle this - please provide ideas below
We have these sumamry stats on the staff dashboard index for pet tasks, adoption applications, and fosters, but I do not like the large purple text. I think it could be refined, with a different colour and perhaps and icon is the clickable link (I am open to ideas).

Please base any design ideas on our theme, which is found here (look around these theme pages and see if there are elements or designs we can use) https://geeksui.codescandy.com/

Hi @kasugaijin ,
Was just playing around trying to come up with some suggestion... Let me know if you like below option for stats

@sarvaiyanidhi thanks for taking a look! I definitely think that’s better. One opinion, I think we could make the two stats for fosters the same colours as for applications, purple and orange. Otherwise it feels like a lot of different colours. Thoughts ?

Sure, let me play around with couple of more options and post design for reference.

Few options let me know if you like any one of it
Option 1

Option 2

Option 3

@sarvaiyanidhi I prefer option 2! Thank you for these


Support https redirect URL

In Entra ID using non-https for the Redirect URI is prohibited (well, on the tenants I'm in at least).
It would be great if it's possible to add support for https Redirect URIs.
There's probably a reason why this isn't supported (yet).
People can probably circumvent this by using a service like ngrok to unblock, but that's not a very secure practice.

MSAL Node requires the return url to be accessible from Insomnia at the time of authentication. Enabling HTTPS would mean an SSL certificate would need to be created and trusted by the browser, on all platforms. This can be complicated and presenting a "certificate not trusted" is a poor user experience.
I believe http redirects can be added via manifest and I am not aware of a way to change it. I could be wrong though

I believe http redirects can be added via manifest

I did not know this would circumvent the validation, will try!

Enabling HTTPS would mean an SSL certificate would need to be created and trusted by the browser, on all platforms. This can be complicated and presenting a "certificate not trusted" is a poor user experience.

This is indeed the reason I expected.
Perhaps using a self-signed certificate can be used and (partly) disable the certificate validation, but that's sub-optimal, indeed.

For now I'll try modifying the manifest itself and think about it if I/we really want that.


support for VirtualBox

Is it possible to use sshto from a Virtualbox client installation?
After running sshto, only the contents of the current directory is printed.
uname -a
Linux roku 5.13.0-37-generic #42-Ubuntu SMP Tue Mar 15 14:34:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
hostnamectl
Static hostname: roku
Icon name: computer-vm
Chassis: vm
Machine ID: 6c4529d835e546e4b96a3758071e0488
Boot ID: 1fb57395bda747cf8062c1dc6a0a3763
Virtualization: oracle
Operating System: Ubuntu 21.10
Kernel: Linux 5.13.0-37-generic
Architecture: x86-64
Hardware Vendor: innotek GmbH
Hardware Model: VirtualBox
locale
Linux roku 5.13.0-37-generic #42-Ubuntu SMP Tue Mar 15 14:34:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
LANG=cs_CZ.UTF-8
LANGUAGE=cs:en_US
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=
dialog --version
Version: 1.3-20201126

I tried to add tracing with 'set -x'. Here is the output:
++ uname -s

[[ Linux == \D\a\r\w\i\n ]]
ls --color=auto

The problem was not caused by Virtualbox or sshto, but by an awk error - see -> https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1845529
After installation gawk sshto works finee

Cool, thanks!)


Bug when loading JSON

I'm using the JSON file:
[
  {"country": "China", "value": "中国"},
  {"country": "Brazil", "value": "Brasil"}
]

The test I'm running is:
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tabulator; import tabulator.processors
>>> table = tabulator.topen('test.json')
>>> table.add_processor(tabulator.processors.Headers())
>>> [row for row in table.readrow(with_headers=True)]
[OrderedDict([(u'country', u'Brazil'), (u'value', u'Brasil')])]

As you can see, only the second element in the JSON array is returned.

Looks to me like the first line is considered headers, whereas in JSON we have the possibility that headers could be extracted from the first line, but it also has values.

Thanks, @vitorbaptista It's definitely a problem in processors.Headers. Paul's wrote a right explanation - processors.Headers just removes the first item from a stream. But keyed json provides headers the other way - so we don't need to add this processor in current implementation. Writing just to clarify what's happening.
Of course I'll make processors.Headers more intelligent to do not break workflow for this case.

@roll actually the JSON handling is a pandora's box :). There are many scenarios we might need to deal with. Off the top of my head, these would be the common ones:

The JSON object is not table-like (how would we know? what would that mean?)
Should we only accept JSON which is at the top level is an array? (I'd say yes for now, but as we use ijson we could actually do smarter things here easily, if needed)
The items in the table are:

objects: do we extract keys from first object, and ensure consistency for following items?
arrays: this is easiest - it is essentially the "same" as a CSV

For sure, JSON support in tabulator is not complete, and it was not supposed to be yet, so I don't think we need to deal with all this right now, but, these are the type of things we'd need to handle.

Yea)
We already have parser.JSON(path='key1.key2') to iter over not-top level array. Have to be documented.
3.1. It's implemented a little bit other way but thanks to you I'm have a good idea now how to make "headers flow" more obvious.

If it helps, datapackage-py seems to be breaking because of this bug https://travis-ci.org/okfn/datapackage-py/builds/98674948

Thanks!
https://github.com/okfn/tabulator-py/blob/master/tests/system/test_topen.py#L138-L154
FIXED


fix fsspec missing param error

Fixed by: https://github.com/Unstructured-IO/unstructured-ingest/pull/313


redis: 7.0.4 -> 7.0.5

Description of changes
Fixes CVE-2022-35951
Release notes: https://github.com/redis/redis/releases/tag/7.0.5
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Doesn't appear to be new but looks like the tests fail for pkgsStatic.redis. Should look at that sometime.
nixpkgs-review happy, macos 10.15 & nixos x86_64. nixosTests.redis & nixosTests.prometheus-exporters.redis pass.

@risicle tests/unit/memefficiency.tcl is failing in ofborg, and tests/unit/maxmemory.tcl has been reported to fail https://github.com/NixOS/nixpkgs/issues/182088. Shall we disable them?

tests/unit/memefficiency.tcl does indeed sound like a test that's more useful to upstream than us.
tests/unit/maxmemory.tcl looks like it's testing actual functionality though. In the linked issue there are a LOT of random failures, and I think it might be a loaded machine machine issue.
Ultimately if this becomes a significant problem we could enable the tests only in a passthru, but I'd like to avoid that if at all possible, because I've no idea how much people actually run them.


rust: bring back 1.65 for aarch64-linux

Description of changes
rustc failds to build on staging for aarch64-linux: https://hydra.nixos.org/build/203858528/nixlog/7, I wasn't able to fix the build, so I brought back 1.65 as a temporary solution

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

#201254

A temporary solution would be, as in #201485, to switch to gcc11Stdenv and pass -lgcc to NIX_LDFLAGS.

A temporary solution would be, as in #201485, to switch to gcc11Stdenv and pass -lgcc to NIX_LDFLAGS.

AFAIU, this should work; testing now.

Closing in favor of #209113.


Backport 2.1: Fix build without MBEDTLS_FS_IO

Fix build with MBEDTLS_PKCS12_C or MBEDTLS_PKCS5_C but without MBEDTLS_FS_IO (missing definition of mbedtls_zeroize in library/pkparse.c).
Issue introduced by #1112, caught by all.sh. This commit passes all.sh on my machine.
Backport of #1184

CI only failed due to known issues (timing tests, compat.sh slow start). Ok to merge.


Running tasks in windows server 2008

Up till now I have been able to pass in  parameters to the task service object constructor and run tasks that are registered under the same account in a development server.
I have read some articles on task security and am a little confused.
On a production server there are tasks registered by different users and I would like the ability to run these tasks using the run method
Could someone please take the time to explain what would be the path of least resistance for me.
Should I reregister these tasks under a local system account/network service account and use the no argument constructor or  would it be preferable to reregister them under a general account and pass in these credentials to the constructor.
If someone could explain to me the best approach I would very much appreciate it .
I have done a bit of digging and would love some feeback
Thanks
Steve
Originally posted: 2011-10-30T15:23:11

Generally the best approach is to use the constructor with the credentials of an account that can create tasks like an administrator account. You can then register the tasks for any user you want by using the parameters of the RegisterTaskDefinition method that specify a user and password. This will then run the task with those supplied credentials and not those used to connect to the remote server in the TaskService constructor.
Let me know if I missed the point of your question.
Originally posted: 2011-10-30T22:03:12

Thank you very much for your prompt response.
It is much appreciated .
Steve
On Sun, Oct 30, 2011 at 11:03 PM, dahall<EMAIL_ADDRESS>wrote:

From: dahall
Generally the best approach is to use the constructor with the credentials of an account that can create tasks like an administrator account. You can then register the tasks for any user you want by using the parameters of the RegisterTaskDefinition method that specify a user and password. This will then run the task with those supplied credentials and not those used to connect to the remote server in the TaskService constructor.
Let me know if I missed the point of your question.
Read the full discussion online.
To add a post to this discussion, reply to this email<EMAIL_ADDRESS>To start a new discussion for this project, email<EMAIL_ADDRESS>You are receiving this email because you subscribed to this discussion on CodePlex. You canunsubscribe on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

--
There is little difference in people, but that little difference makes a big difference. That little difference is attitude. The big difference is whether it is positive or negative. - W. Clement Stone
Originally posted: 2011-10-31T08:13:27


Spark bench fails on latest version of spark 2.4.2.

Spark-Bench version (version number, tag, or git commit hash)
2.3.0
Details of your cluster setup (Spark version, Standalone/Yarn/Local/Etc)
yarn
Scala version on your cluster
2.12.8
Your exact configuration file (with system details anonymized for security)
spark-bench = {
  spark-submit-config = [{
    workload-suites = [
      {
        descr = "One run of SparkPi and that's it!"
        benchmark-output = "console"
        workloads = [
          {
            name = "sparkpi"
            slices = 10
          }
        ]
      }
    ]
  }]
}

Relevant stacktrace
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
2020-03-05 15:05:59,292 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Exception in thread "main" java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)Lscala/collection/mutable/ArrayOps;
	at com.ibm.sparktc.sparkbench.cli.CLIKickoff$.main(CLIKickoff.scala:26)
	at com.ibm.sparktc.sparkbench.cli.CLIKickoff.main(CLIKickoff.scala)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.spark.deploy.JavaMainApplication.start(SparkApplication.scala:52)
	at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:849)
	at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:167)
	at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:195)
	at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:86)
	at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:924)
	at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:933)
	at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
2020-03-05 15:05:59,418 INFO util.ShutdownHookManager: Shutdown hook called
2020-03-05 15:05:59,419 INFO util.ShutdownHookManager: Deleting directory /tmp/spark-dc94b54b-b6ff-46e4-a4b6-dde506128cee
Exception in thread "main" java.lang.Exception: spark-submit failed to complete properly given these arguments:
	/usr/local/spark/bin/spark-submit
--class
com.ibm.sparktc.sparkbench.cli.CLIKickoff
--master
yarn
/home/hadoop/spark-bench_2.3.0_0.4.0-RELEASE/lib/spark-bench-2.3.0_0.4.0-RELEASE.jar
{"spark-bench":{"spark-submit-config":[{"workload-suites":[{"descr":"One run of SparkPi and that's it!","workloads":[{"name":"sparkpi","slices":10}]}]}]}}
	at com.ibm.sparktc.sparkbench.sparklaunch.submission.sparksubmit.SparkSubmit$.submit(SparkSubmit.scala:51)
	at com.ibm.sparktc.sparkbench.sparklaunch.submission.sparksubmit.SparkSubmit$.launch(SparkSubmit.scala:34)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch$.com$ibm$sparktc$sparkbench$sparklaunch$SparkLaunch$$launch$1(SparkLaunch.scala:58)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch$$anonfun$launchJobs$2.apply(SparkLaunch.scala:65)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch$$anonfun$launchJobs$2.apply(SparkLaunch.scala:65)
	at scala.collection.immutable.List.foreach(List.scala:381)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch$.launchJobs(SparkLaunch.scala:65)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch$.main(SparkLaunch.scala:38)
	at com.ibm.sparktc.sparkbench.sparklaunch.SparkLaunch.main(SparkLaunch.scala)

Description of your problem and any other relevant info
/bin/spark-bench.sh ./examples/minimal-example.conf gives above error.

The issue is on your end given that you're using Scala 2.12 but this API is built on Scala 2.11

@LorenzBuehmann ,is there any updated versions available? or some mention someone who working on it !.
any way thanks for the reply.

I don't know, I'm not part of the project team.
But to be fair, you could simply checkout the project and make the changes for a newer Spark version as well as Scala 2.12. I mean, it's a simply Scala project with an SBT file.

checkout sparkMeasure, which works with spark3: https://github.com/LucaCanali/sparkMeasure


New feature-- 2D breakout game

Describe the solution you'd like
We can add a 2D breakout game, which is an intermediate javascript project
https://user-images.githubusercontent.com/64382399/107606823-59d7b800-6c5d-11eb-809d-d7cfba0d7374.mp4

@Vishal-raj-1 let me know if you want to add this game to the projects section:-)

@frappelatte28 Yes !! You can start.

@frappelatte28 Any update? Kindly reply within 2 days or I have to close this.

You can close it, I am not working anymore on this issue.