text:
weave-npc blocking connections with valid network policy after a period of time (2.6.0)

What you expected to happen?
Similar to #3761, we are seeing traffic being blocked by weave-npc, but we are using network policies. I would expect traffic to not be blocked by NPC with valid network policy in place
What happened?
We have seen now, consistently (about once every 1-2 weeks) traffic gets blocked between pods inside of a namespace where traffic was working fine earlier.  After we debugged the issue, and saw the ipset's on the host to not have valid entries for the pods, we restart weave on the host, and the ipsets become populated, and traffic continues to flow.
How to reproduce it?
I wish we had an easy way to consistently reproduce this issue, but we are beginning to see this issue nearly every week within one specific cluster.
Anything else we need to know?
cloud provider: aws
custom built cluster using in house automation.
Versions:
# ./weave version
weave script 2.6.0
# docker version
Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
# uname -a
Linux ip-10-0-173-150 4.15.0-1056-aws #58-Ubuntu SMP Tue Nov 26 15:14:34 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T16:54:35Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Logs:
Unfortunately, these logs do not show the weave logs before restart, but when we run into this issue again (in a week or so), we will get those logs and update this issue
https://gist.github.com/naemono/31df744c7ee6b48dba7b554e06553f4b
When this issue is happening, we begin to see a spike in weavenpc_blocked_connections_total from prometheus:

@naemono thanks for reporting the issue

After we debugged the issue, and saw the ipset's on the host to not have valid entries for the pods,

when we run into this issue again (in a week or so), we will get those logs and update this issue

Please gather the weave-npc logs, and ipset dumps. add/detion of entry to ipset's are logged. so we should be able to track under what scenario ipset is going out-of-sync from desired state

We've also been noticing this for weeks now with the latest weave. In a deployment of n pods, we sometimes have x broken endpoints because, while the pods show as healthy & are there behind the load balancer, network is absolutely blocked (as shown in the logs). Kicking such pods to other nodes, or restarting weave on the node fixes the issue immediately. It occurs several times week now. We haven't been able to track a reproduction just yet. The weave uptime is ~4mo-6mo.

@Quentin-M @naemono your clusters are upgraded from previous version of weave-net or new clusters?

@murali-reddy the staging0 cluster @naemono mentions has been upgraded from previous versions of weave.
Furthermore, the logs you asked for for updating IP sets, I haven't seen those in the weave-npc logs, do we need to change/update the debugging level to collect that information?

Dear @murali-reddy,
We have been investigating today as we do have a non-prod case right now, where traffic is blocked between pods.
As it appears, numbers of our nodes have the IPSets for the From/To selectors as well as the associated iptables rule. Now, the node that hosts the destination pod, does not have either From/To IPSets. Looking at the AddPod/UpdatePod logs across the fleet, every single nodes (40+) got the event for the pod creation. However, looking at the nodes that received AddNetworkPolicy/UpdateNetworkPolicy, we are only count 10 nodes here, thus, also seeing only 10 nodes that created the From/To IPSets (looking for "creating ipset" & the IPSet hash), and the associated iptables rule. Therefore, as the IPSets were not provisioned, neither the From/To pod IPs were added to such non-existing IPSets. As we were looking at other recently created network policies in our logs, we did notice that only 10 nodes, the same 10 nodes, caught the event.
Therefore, I am guessing that the NetworkPolicy informer/watch is broken, whereas the Pod informer/watch functions (but unable to act given the required IPSets are unavailable). As we restart weave, all network policies are queried, state is reconciled, fixing the traffic.

We also have this issue going on in another cluster right now
# Log from application
[cdb-7a593229-07f8-493f-91a0-4adea89eaf45-0] W200204 20:43:17.899119 5774009 vendor/google.golang.org/grpc/clientconn.go:1304  grpc: addrConn.createTransport failed to connect to {cdb-7a593229-07f8-493f-91a0-4adea89eaf45-2.cdb-7a593229-07f8-493f-91a0-4adea89eaf45-internal.7a593229-07f8-493f-91a0-4adea89eaf45:26257 0  <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp 172.16.152.4:26257: i/o timeout". Reconnecting...

# so -0 of the statefulset, cannot speak to -2 member on node 10.0.169.28
$ kubectl get pods -n 7a593229-07f8-493f-91a0-4adea89eaf45 -o wide
NAME                                         READY   STATUS    RESTARTS   AGE    IP             NODE                                         NOMINATED NODE   READINESS GATES
cdb-7a593229-07f8-493f-91a0-4adea89eaf45-0   2/2     Running   0          4d3h   172.16.72.4    ip-10-0-141-103.us-west-2.compute.internal   <none>           <none>
cdb-7a593229-07f8-493f-91a0-4adea89eaf45-1   2/2     Running   0          4d3h   172.16.112.2   ip-10-0-152-110.us-west-2.compute.internal   <none>           <none>
cdb-7a593229-07f8-493f-91a0-4adea89eaf45-2   2/2     Running   0          4d3h   172.16.152.4   ip-10-0-169-28.us-west-2.compute.internal    <none>           <none>

root@ip-10-0-169-28:~# iptables -L -nv | grep 7a593229-07f8-493f-91a0-4adea89eaf45
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set weave-cN1skCFLoaYj*t2Ym.tmuLY%4 dst /* DefaultAllow ingress isolation for namespace: 7a593229-07f8-493f-91a0-4adea89eaf45 */
    0     0 WEAVE-NPC-EGRESS-ACCEPT  all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set weave-~9IS!W{C7.msGij/f[%w27j?u src /* DefaultAllow egress isolation for namespace: 7a593229-07f8-493f-91a0-4adea89eaf45 */
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set weave-~9IS!W{C7.msGij/f[%w27j?u src /* DefaultAllow egress isolation for namespace: 7a593229-07f8-493f-91a0-4adea89eaf45 */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set weave-+d#CMWwwpfatM/b:D@7LB%VD8 src match-set weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx dst /* namespaces: selector: allow-namespace-in-default-deny.organization.cloud -> pods: namespace: 7a593229-07f8-493f-91a0-4adea89eaf45, selector:  (ingress) */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set weave-0d{4DK:*zt}w#16(f8?tCqqVR src match-set weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx dst /* namespaces: selector: name.organization.cloud=7a593229-07f8-493f-91a0-4adea89eaf45 -> pods: namespace: 7a593229-07f8-493f-91a0-4adea89eaf45, selector:  (ingress) */
    0     0 ACCEPT     all  --  *      *       172.16.144.0         0.0.0.0/0            match-set weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx dst /* cidr: 172.16.144.0/32 -> pods: namespace: 7a593229-07f8-493f-91a0-4adea89eaf45, selector:  (ingress) */
    0     0 ACCEPT     all  --  *      *       172.16.0.1           0.0.0.0/0            match-set weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx dst /* cidr: 172.16.0.1/32 -> pods: namespace: 7a593229-07f8-493f-91a0-4adea89eaf45, selector:  (ingress) */
    0     0 ACCEPT     all  --  *      *       172.16.192.0         0.0.0.0/0            match-set weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx dst /* cidr: 172.16.192.0/32 -> pods: namespace: 7a593229-07f8-493f-91a0-4adea89eaf45, selector:  (ingress) */
root@ip-10-0-169-28:~# ipset list 'weave-0d{4DK:*zt}w#16(f8?tCqqVR'
Name: weave-0d{4DK:*zt}w#16(f8?tCqqVR
Type: list:set
Revision: 3
Header: size 1024 comment
Size in memory: 200
References: 1
Number of entries: 1
Members:
weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx comment "namespace: 7a593229-07f8-493f-91a0-4adea89eaf45"
root@ip-10-0-169-28:~# ipset list 'weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx'
Name: weave-{V*Z4^{Xw5:O?*rK*MP_#yTZx
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 88
References: 6
Number of entries: 0
Members:
root@ip-10-0-169-28:~#

Would expect to see some rules in the ipset on that node..
weave-npc logs from 10.0.169.28
https://scpycae8-cluster-storage.s3-us-west-2.amazonaws.com/weave-logs/weave-npc.logs
weave logs
https://scpycae8-cluster-storage.s3-us-west-2.amazonaws.com/weave-logs/weave.logs
weave pod has been running for 62 days
$ kubectl get pod -n kube-system -o wide | grep  ip-10-0-169-28
weave-net-mwrmn                                                      2/2     Running   0          62d    10.0.169.28     ip-10-0-169-28.us-west-2.compute.internal    <none>           <none>

Added some details / questions to my post above.

We went all the way down on this one.
So it appears that all 40+ of our weave-npc containers panicked all at once.
INFO: 2019/12/18 23:29:45.395235 EVENT UpdateNetworkPolicy <redacted>
INFO: 2019/12/18 23:29:45.395556 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.400406 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.404054 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.407970 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.411377 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.415293 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.419160 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.422601 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.425904 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.429113 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.432321 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.435514 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.438740 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.441963 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.445437 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.448684 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.452192 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.455496 deleting rule <redacted> from "WEAVE-NPC-INGRESS" chain
INFO: 2019/12/18 23:29:45.458663 destroying ipset: &npc.selectorSpec{<redacted>}
ERROR: logging before flag.Parse: E1218 23:29:45.469138   31331 runtime.go:66] Observed a panic: "assignment to entry in nil map" (assignment to entry in nil map)
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:72
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:65
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:51
        /usr/local/go/src/runtime/asm_amd64.s:573
        /usr/local/go/src/runtime/panic.go:502
        /usr/local/go/src/runtime/hashmap.go:507
        /go/src/github.com/weaveworks/weave/npc/selector.go:157
        /go/src/github.com/weaveworks/weave/npc/namespace.go:347
        /go/src/github.com/weaveworks/weave/npc/controller.go:146
        /go/src/github.com/weaveworks/weave/npc/controller.go:78
        /go/src/github.com/weaveworks/weave/npc/controller.go:145
        /go/src/github.com/weaveworks/weave/prog/weave-npc/main.go:316
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/controller.go:202
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/controller.go:309
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/delta_fifo.go:444
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/delta_fifo.go:444
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/controller.go:150
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/controller.go:124
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:134
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88
        /go/src/github.com/weaveworks/weave/vendor/k8s.io/client-go/tools/cache/controller.go:124
        /usr/local/go/src/runtime/asm_amd64.s:2361

The issue lies in the npc/selector#deprovision function. My guess would be that the *selectorSpec was changed by an informer in another goroutine as the structure is not deep copied nor locked, and therefore made the loop crash. And then, as you can see in the trace, this panic bubbles up all the way back to the npController.Run internal loop, which crashes the whole goroutine dealing with Network Policies, without making weave-npc itself crash/restart - leaving you with a weave-npc working with 2 controllers instead of 3 (or only one if you consider that the Pod controller can't function without the IPSets created by the Network Policy controller).
The reason we've been seeing 10 nodes still working is that those 10 weave-npc containers have been restarted by human interventions (while trying to unblock those nodes), or by other natural causes (e.g. node restart).
Beyond protecting the deprovision function from panicking with the appropriate locks / deep copies, I suggest either a/ we make the controllers recover from the panics & restart b/ we make the whole weave-npc binary crash from any one panic from the controllers. Solution a/ is better as it avoids resetting all the IPSets/rules/etc, however b/ may allow for a clean start (no cache, no broken state, etc). We note however that if we are to do b/, as all of our weave-npc nodes crashed all at once, we would have suffered a cluster-wide network downtime as weave-npc would be clearing / resetting everything, which would be really - really bad. (why do you reset upon start again instead of reconciling??).

@Quentin-M thanks for digging deep and finding the root cause of the issue you are facing
So as per the you last comment
 crashes the whole goroutine dealing with Network Policies, without making weave-npc itself crash/restart - leaving you with a weave-npc working with 2 controllers instead of 3 (or only one if you consider that the Pod controller can't function without the IPSets created by the Network Policy controller
I assume this was the reason weave-npc running on the node does not process any events from API server and potentially resulting in traffic from new pods to be dropped. We had this issue reported earlier, not sure in your case cause was same https://github.com/weaveworks/weave/issues/3407#issuecomment-423499250
But irrespective panic need to be prevented and handled gracefully by weave-npc. Just so you know same logic was there in earlier version as well. So i am not sure why you are hitting this issue only with 2.6.
regarding question on reconciliation. I agree weave-npc needs improvements. We have a tracking issues which is not addressed yet.
https://github.com/weaveworks/weave/issues/3586
On weave-net pod restart, it should not flush all iptables chain and ipsets which would mean disruption of services. There should be just reconciliation. Also there should be a periodic sync task that does reconciliation which is typical of controllers.

Dear @murali-reddy,
Thanks for your answer.

But irrespective panic need to be prevented and handled gracefully by weave-npc. Just so you know same logic was there in earlier version as well. So i am not sure why you are hitting this issue only with 2.6.

No, I did not claim that we've only seen the issue in 2.6. Indeed, the deprovision code has been unchanged for a long-time. I imagine that the conditions creating the panic in the function only seldom occurs & requires good timing - which would be why the issue hasn't been that widespread.

On weave-net pod restart, it should not flush all iptables chain and ipsets which would mean disruption of services. There should be just reconciliation. Also there should be a periodic sync task that does reconciliation which is typical of controllers.

Thanks for confirming the intent. It has been (personally) our biggest worry using Weave, as some of our financial services are sensitive to network blips. The scope of this work (and its required testing) seems fairly large. Is there any plan from WeaveWorks to iterate on this?
From our side, if you're fine with it, we'll be happy to submit a short PR to make the controllers recover from panics, as we'd like to fix (in other words: restart) our 30+ broken nodes, without having to handle other restarts if it is related to a bad network policy resource.

FYI, we are also testing what would happen with having a reconciliation loop outside of "0" for pods/namespaces over here, and will loop back...

From our side, if you're fine with it,we'll be happy to submit a short PR to make the controllers recover from panics

@Quentin-M Weave Net is an Open Source project please feel free to submit  PR

Thanks for confirming the intent. It has been (personally) our biggest worry using Weave, as some of our financial services are sensitive to network blips. The scope of this work (and its required testing) seems fairly large. Is there any plan from WeaveWorks to iterate on this?

As of now its not planned for next major release. It may be considered. But if you require a guaranteed fix  you can reach to Weaveworks commerical support. Again any PR would be welcome.

@murali-reddy We've added a reconciliation loop for pods/namespaces/netpols over here, and have it running in a couple non-production clusters, and are not noticing any immediate issues with doing this.  Was there any reason in particular that this wasn't initially implemented?  I'm just wondering if others that are more intimately familiar with the code could point out some downfalls of this?  thanks for any insights you can provide.

From our side, if you're fine with it,we'll be happy to submit a short PR to make the controllers recover from panics

After some internal discussions, we ended up thinking that instead of making the controllers recover from panic, as some of the structures will still be loaded in memory - instead we should consider removing the reset upon startup, and propagate the panic to make the whole weave-npc container crash & restart cleanly. From there, reconciliation should be enough to clean up / catch up / go forward.
However, just like @naemono, we are not sure why the reset was in place at all in the beginning (given it obviously creates downtime upon npc restart, which doesn't make much sense - 10secs in our case), so a bit wary. Assume if we were to remove the initial reset, we should either do an initial reconciliation (what is on the host vs. what is desired state), or make the provision/deprovision based on some sort of 3-way decision (what's on the host, what is "current", and is "desired").
Thank you!

However, just like @naemono, we are not sure why the reset was in place at all in the beginning (given it obviously creates downtime upon npc restart, which doesn't make much sense - 10secs in our case), so a bit wary.

@Quentin-M Agree. We should just perform reconciliation instead of reset at the start of weave-npc pod

We've added a reconciliation loop for pods/namespaces/netpols over here, and have it running in a couple non-production clusters, and are not noticing any immediate issues with doing this. Was there any reason in particular that this wasn't initially implemented? I'm just wondering if others that are more intimately familiar with the code could point out some downfalls of this? thanks for any insights you can provide.

Did you made change to informer's resyncPeriod? This will cause load on the API server as informer on each node will relist the API object at the configured duration. What is ideal is we design controller which at periodic interval list the cached objects and perform sync.
Either way i think the problem was not missed events from the API server rather the go routine that crashed stopped processing events. @Quentin-M please feel free to subit a PR to perform reconciliatio instead of reset.

@murali-reddy
Either way i think the problem was not missed events from the API server rather the go routine that crashed stopped processing events
Strange thing is, we're not seeing the crashing, we are only seeing the network anomalies from the missing rules, which is why we're testing having a reconciliation period.  If the only downside is increased apiserver load, I think that's much preferred than having missed rules inside the cluster that are causing failing network communication.
We're still testing the changes in our clusters, and will report back, likely with a PR that keeps the default at "0", but allows tuning of the reconciliation interval.

Strange thing is, we're not seeing the crashing, we are only seeing the network anomalies from the missing rules,

@naemono then we are possibly looking at different issue than what @Quentin-M observed. While reconciliation should help the fix the problem but there must be latent issue which is not updating the ipset appropriatley. It would be nice to get to root cause of the problem. I can not access the logs shared by you. Please see if there is any unexpected deletions from ipset

@murali-reddy Sorry about the logs
https://bb83126f306f400e87721c0482fcd983-logs.s3-us-west-2.amazonaws.com/weave-logs/weave-npc.logs
https://bb83126f306f400e87721c0482fcd983-logs.s3-us-west-2.amazonaws.com/weave-logs/weave.logs
I've verified that these are, indeed, public, and accessible.

@Quentin-M it would be better if you opened a separate issue since the two threads of conversation are hard to maintain.
The code reporting your panic is here:
https://github.com/kubernetes/apimachinery/blob/210bcde8e5a7715fe776460ca1df1a3f2738725e/pkg/util/runtime/runtime.go#L66
However it appears to me that the intention is to re-raise the panic and hence exit the whole program.  I am mystified why it keeps on running.

@naemono thank you very much for the logs but I think the NPC log does not go back far enough - we only see it blocking things and not what led up to that state.  Do you have earlier logs?  (Or, if it is reproducible on restart, restart the pod and send us the whole log).

@bboreham @murali-reddy I see that the logs seems to default to info level
  --log-level=info                                           logging level (debug, info, warning, error)

are the npc changes not shown at info level?  As mentioned by @ephur earlier, we're not seeing them at all.

We actually set npc to debug level in the manifest. The problem I was commenting on is that your file starts at a time after the interesting part.

I'm going to go ahead and close this, and we have recently discovered that the panic referenced by @Quentin-M actually IS the root cause of our issue as well and https://github.com/weaveworks/weave/issues/3771 is that continued discussion.  Opening a PR now to attempt to crash the whole npc app when an internal panic occurs.

I'm going to re-open this issue to cover the underlying symptom described at https://github.com/weaveworks/weave/issues/3764#issuecomment-582230881 - a panic causes a hang not a restart.
#3771's description covers what should happen after a restart, although the subsequent discussion is mostly about what causes the hang.

authors: Quentin-M bboreham ephur murali-reddy naemono


text:
Add functions to combine lists of filters via and/or

Closes https://github.com/weaviate/weaviate-python-client/issues/893

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.22%. Comparing base (310bd06) to head (c733e5b).
Report is 115 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #920      +/-   ##
==========================================
- Coverage   95.49%   95.22%   -0.27%
==========================================
  Files         167      173       +6
  Lines       17198    17742     +544
==========================================
+ Hits        16423    16895     +472
- Misses        775      847      +72

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

source: gharchive/pull-request

authors: codecov-commenter dirkkul

repo: weaviate/weaviate-python-client

license_type: permissive

license_source: github-api


text:
docs: add announcing Rsbuild v0.4

Summary
Add announcing Rsbuild v0.4.
Related Links
https://github.com/web-infra-dev/rsbuild/discussions/1420
Checklist

[ ] Tests updated.
[x] Documentation updated.

hello @chenjiahan i believe you've added a wrong git tag v1.0.0 by incident

repo: web-infra-dev/rsbuild

license: MIT


text:
resolve to wrong module with aliasFields

webpack-test/cases/resolving/browser-field should pass

Here are the missing pieces:

node_modules is missing from https://github.com/web-infra-dev/rspack/tree/main/webpack-test/cases/resolving/browser-field

To pass this: https://github.com/web-infra-dev/rspack/blob/6f85b0360cf8a65569c2d5188c882269c891688b/webpack-test/cases/resolving/browser-field/index.js#L2

We need to set browserField: true in the webpack config
https://github.com/web-infra-dev/rspack/blob/6f85b0360cf8a65569c2d5188c882269c891688b/packages/rspack/src/config/zod.ts#L321-L325
But it seems like there is a big mismatch between all these configs - See https://www.rspack.dev/config/resolve.html#resolvealiasfield and https://webpack.js.org/configuration/resolve/#resolvealiasfields

I'm still investigating on how to pass
https://github.com/web-infra-dev/rspack/blob/6f85b0360cf8a65569c2d5188c882269c891688b/webpack-test/cases/resolving/browser-field/index.js#L40-L43

For debugging what's being passed into oxc_resolver:
cd webpack-test
OXC_RESOLVER=TRACE pnpm t -- -t "resolving browser-field" | grep  alias_fields

and you should see alias_fields: [["browser"]]

source: gharchive/issue

authors: Boshen ahabhgk

repo: web-infra-dev/rspack


text:
v3.0 doesn't send webpush

NOTE: Please test in a least two browsers (i.e. Chrome and Firefox). This
helps with diagnosing problems quicker.

Please confirm the following:

[X] I have read the README entirely
[X] I have verified in the issues that my problem hasn't already been resolved

Setup

Please provide the following details, the more info you can provide the
better.

Operating System: amazon-linux-ami/2017.09
PHP Version: 7.2.3
web-push-php Version: 3.0

Please check that you have installed and enabled these PHP extensions :

[X] gmp
[X] mbstring
[X] curl
[X] openssl

Please select any browsers that you are experiencing problems with:

[ X] Chrome
[ X] Firefox
[ X] Firefox for Mobile
[X ] Opera for Android
[X ] Samsung Internet Browser
[X ] Other

Please specify the versions (i.e. Chrome Beta, Firefox Beta etc).

Problem
I use this library for 2 years. Yesterday I saw the new release (3.0) but it's not possible to receive any webpush.
It returns true and seems like all pushes are gone. But I can not see any webpush. When I try same code with v.2.0 I can see all web pushes on my screen. So It's not possible to say what the problem is since there is no error on the screen. But It's look like  problem is related with v 3.0
I tried this case more than 10 times I reinstalled the library but nothing has changed.
Expected
I should see web pushes that I send. (I see the webpushes if I try with v.2.0)
Features Used

[X] VAPID Support
[X] GCM API Key
[X] Sending with Payload

Example / Reproduce Case
$payload = '{"title":"My Title","body":"My Body","zbid":16515,"icon":"//dbfukofby5ycr.cloudfront.net/notification_13/0/1/2016-11-07/3aba8-TransparentBackBlackFore-03.png","link":"https://www.example.com/"}';
$Authentication = Array(
'VAPID' => Array(
'subject' => 'mailto:x@example.com',
'publicKey' => 'YYYY',
'privateKey' => 'XXXX'
),
'GCM' => 'ZZZZ'
);
$webPush = new WebPush($Authentication,Array(),20,Array('verify'=>false));
$webPush->setAutomaticPadding(false);
$endpoint = 'XXX';
$userpublic='XXX';
$usertoken = 'XXX';
$res = $webPush->sendNotification($endpoint,$payload,$userpublic,$usertoken,false);
$webPush->flush();

Thanks for the feedback!
This looks like a duplicate of #142, see the discussion there :)

authors: Minishlink ozgurhangisi

repo: web-push-libs/web-push-php

license: mit

license_source: bigquery


text:
Possibility exists for tasks to be created without a reminder

Describe the bug
I found some tasks in the OSS production instance where the task is enabled and the nextRunAt is in the past (2022-08-24T03:00:54Z , it is 9/16/2022 today).
Workaround: Disable and Enable the task.
Steps to reproduce
unknown
Expected behaviour
We need to add logic to accommodate this.

After digging in, I was able to see these tasks do not have reminders set for them.
I believe this is because we call WriteState() before we EnsureReminder().
https://github.com/web-scheduler/web-scheduler/blob/3f5fb5e6aeeea270750090830c5c483ac1875dd8/Source/WebScheduler.Grains/Scheduler/ScheduledTaskGrain.cs#L111-L125
If the reminder gets created but the write fails, that should be OK as the reminder will correct itself on the first tick and disable.

repo: web-scheduler/web-scheduler


text:
[feat/fix]: Change black-background logos to transparent

Changed black background logos for transparent ones (Issue 14)

Hmm, here is where I downloaded the picture, can someone try https://devprotocol.xyz/

Hmm, here is where I downloaded the picture, can someone try to help this PR
Link: https://devprotocol.xyz/

You can right click each picture and download it.

Please try to get the specific size in Figma.

We can set a max-w to all of the images to give them a optimal size. What do you think @vinzvinci?

Okay, you did right @sirinoks, it's my fault for giving that image xD. I will merge this, so @krishguptadev can do that suggestion.

authors: krishguptadev sirinoks vinzvinci


text:
Issue in DatePicker Static Date when changed type from date to month

In Datepicker component inside Forms section,
When type is initially set to 'date' and static value is set then it works fine .  Ref below img :

But when the type is set to month, it doesn't works instead shows blank line. This is because default value is set as 'yyyy-mm-dd' which is not acceptable for type=month. For month type it must be 'yyyy-mm'.

So I think a new story must be created here for the case of type-month with 'yyyy-mm' as a static value to let the users know that both static date format is different for type month.
Should I create a PR for this ?

TY 🥳
Closed as completed by #837


text:
Interpolate toward look position while finger is down

related: https://github.com/webaverse-studios/CharacterCreator/issues/147
issue:
https://user-images.githubusercontent.com/60634884/221713915-cd25676e-bf2b-4eb7-84dc-86f060875017.mp4
result:
https://user-images.githubusercontent.com/60634884/221713980-f5079f74-c90a-4dc3-8b3e-b3433ed9003c.mp4

Tested on mobile, as I only tested on pc before, but seems a commit might be missing as it doesnt work as in the video :) @tcm390 did you push all your changes?

repo: webaverse-studios/CharacterCreator


text:
Design: enemies

We should decide what an enemy (in the Filter) looks like. There should be some clear design pattern behind what is hostile. It could be different for each filter.
Some random examples (with many different styles):

Perhaps the enemies could draw design ideas from the forces of bit rot and data corruption that at times manifest in the world. Something like a glitchy shadowy person that's deep dreamed or generated by a data set of spam / ads. Maybe the enemies can be designed in any which way but are stylized by their textures / modeling / animations looking corrupted.

Perhaps they are EYE cultists, aggro thieves that see people within the zones as sheep and ambush those that attempt to cross the Great Filter. These cultists are almost always wearing masks with the eye on them.

Or perhaps enemies are stylized by being low effort / quality, which made them easy to be corrupted and controlled by the AIs. As such a result, they all have a red aura / glowing eyes.

Eye makes sense, though I think whether the antagonizing force is humanized an important distinction. Fighting a group of people is different from fighting a toybox of symbols.

Feedback from a friend on those style transfer sprites:
Probably fair use in the same way that if you drew your own version of it using originals for reference would be. If challenged, it would be good PR for the project as it would spark discussions.
It's an interesting play on the corruption happening in the world with enemies well on their way along the path of entropic decay. Also, the set of sprites chris novello made are loosely related to the keycard also.

The main problem I have with raw sprites is that they make for poor 3d gameplay, especially in VR, so I think volume and polygonality is required.
That doesn't mean that we can't have sprites attached, or glitches as part of the textures. But the enemies should have volume, so we can e.g. blow them up to huge proportions as bosses and not have to worry about the wrong sprite angle ruining the experience.

Chewing on some ideas here...
Potential enemy Traits:

Robots (truly soulless AIs)
Darkness (what's opposite of solarpunk)
EYE
Corruption
Glitchiness
Bit rot
Cursed
Wings / Horns
Spiders
Ents
Ads (time leechers)

One way we can think of them is through style or skins, like how zombies are to humans. This way any type of pet or character could be made into an enemy through a creative process. For example, if there was an evil version of blob pet, what would it look like? How scalable is the process? How are they marked?
If the first Great Filter is forest inspired, we could start with creatures there. They would have to be small since each modular piece isn't all that big. Forests are organic type places so I like the idea of having some kind of uncanny robot enemies. Its as if there's a villain out there that is attempting to create their own AIs (outlawed).

My leading idea was to take any model, and effect it through a very distinct corruption texture. This would allow us to reuse essentially any model and make a corrupted version of it with no effort.
It would require designing a pattern and implementing the shader but that seems far easier and more flexible than designing a new set of models.

Playing around with shaders:

What if corruption is caused by Silk Worms?

I like this. The visuals are pretty high contrast and would apply to anything without blending too much color, and the idea of a Silk Worm is a good double entendre.
Only issue I can see is that silkworms create silk rather than necessarily destroy them, but I think it's an interesting piece of terminology that you could imagine the characters using as slang.

Shadertoy link isn't working to view, unfortunately.

Silk Worms corrupt objects to produce Silk as a byproduct. A silk fountain is a place where silk worms live and corrupt the underground and stay there in symbiosis with trash objects being thrown down holes in the ground.
If you let silk worms run rampant, you get places like the Filters, where there is tons of Silk but also a lot of corrupted people and things as a result.
Corruption happens when you touch a silk worm, and is irreversible since the data areas are overwritten with the resulting Silk -- which is how the worms operate.

Shadertoy link isn't working to view, unfortunately.

Updated, but it's not that interesting.

The above explanation does take away from the mystery of corruption being a random malevolent force, but I feel like this narrative already has much better things (lisk) suited for that role.

What if silk worms ate nfts and corrupted things to produce silk? would make a nice loop of nfts -> fungible tokens -> nfts
There can be an address people can send nfts to, which then takes note of the sender before transfering the nft to https://opensea.io/accounts/burnaddress

That's exactly what I meant. It's a form of recycling the Silk used to mint NFTs, logically speaking.
However, the amount of SILK you get back should be a lot less than what you put in to mint, like 10%, to prevent this from being gamed.
I imagine you'd just go to the silk fountain and throw in your unwanted NFTs and wait for the silk to pop out.

If we like that idea, makes sense to bake it into the lore and possibly come up with a silk worm model.
IRL silk worm even has a pretty decent design.

How about we make them really small so its like a cool shader and perhaps in a cutscene or lore art they're under a microscope and look all wormy and stuff?

Other than this cool scene what is the benefit?
Making things small makes it harder to show and explain them. This could have some huge side benefit to lore which compensates but I don’t see it.

I like the recycling idea, makes sense.
In terms of design, size, etc, you could go the complete opposite and have them be gigantic, even.
PSO2 has these cute giant robots that you feed items to, for example:

Having the fountain be like a home for a large silkworm could work. Design for it would be key, though, do you want it to be creepy, friendly, etc?
As for handheld size, closest thing I can think of is an Antlion grub from HL:
https://half-life.fandom.com/wiki/Antlion_Grub

Yup the juicy grubs from hl2 crossed my
mind too, pleasing to throw and squish. There could be different sizes.
For the fountain I see either some anthill like thing, or just some ripples or texture on the ground that makes it intuitive that you should dig there. It is a structure we would repeat so it should be recognizable, but not necessarily elaborate.

As for style I think we are arriving at some principles to use:
Go for emotional impact
Weave in symbology
Quality is how much thought was put in
Think about lore and plot holes
It’s ok to be weird
It’s ok to write love letters
It’s ok to be silly
Within those constraints I think there is still tons of room for experimentation.

If we're just using corruption over top can just make geometry for the enemies

Corruption it is!

authors: Vianvolaeus avaer madjin

repo: webaverse/app


text:
[TASK] Integrate back-end with Pool Metadata Table in Hubble Stats

Implement functionality to dynamically fetch and display the data for the Pool Metadata Table component on Hubble Stats.

@elkremroot feel free to add additional context here! After that remember to add Assignees and Estimation.

Steps include:

Update the fetchingOnChainData function to generate Signature Bridge and Treasury Address, and Creation time
Utilize data generated from fetchingOnChainData to display data for vanchors
Getting up-to-date wrapping fees using ViemClient and Fungible Token contract abi

repo: webb-tools/webb-dapp


text:
Truncate sidebar IP if too long and update Buttons in the sidebar

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?
Long IP Addresses break out of the sidebar and display in the main container.
What is the new behavior?
IP Addresses should truncate if they are too long.
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Truncating and social links work as intended. However, and this might be nit picking or can be dealt with in a subsequent PR, but the background of the Your IP section looks unsymmetrical from the main page area.

I think it may be improved with the use of a rectangular background (non-rounded corners) for the Your IP component and removing the rounded background shape on the main page. Thoughts? @nepoche

Thanks for the comments - I believe any issues regarding rounded corners / box shadowing will be addressed in the palette update

authors: dutterbutter nepoche


text:
usage of exclude and include options for database not possible

according to this function-call
https://github.com/webdevops/go-sync/blob/232268d689c415aeffb4f11b0083a3cc3590a2e6/sync/server_sync_database.go#L131
the usage of exclude / include options for syncing a database is not possible since useFilter is always populated with "false".
can this be fixed or is there an undocumented feature to use exlude / include on databse tables?

Same problem here

I patched it manually and changed false to true and works fine ;)
gosync-linux-arm.zip
gosync-linux-arm64.zip
gosync-linux-x64.zip
gosync-osx-x64.zip
gosync-windows-x64.zip

authors: georgringer misterboe nabossha

repo: webdevops/go-sync


text:
Add support for bower

As wanted in https://github.com/newtriks/generator-react-webpack/issues/157, the webpack configuration should be able to read bower files.

Included in new release 0.3.2

repo: weblogixx/react-webpack-template


text:
Split transposed convolution to convTranspose2d

Spec change https://github.com/webmachinelearning/webnn/pull/214

Close it with #145

repo: webmachinelearning/webnn-polyfill


text:
Unify Printer and SchemaPrinter output for block strings

Adds StringBlock::print() method, an equivalent of printBlockString() function from graphql-js. It's used to print string blocks in Printer and SchemaPrinter.
Relevant changes in the reference implementation:

https://github.com/graphql/graphql-js/pull/1751
(commits https://github.com/graphql/graphql-js/commit/ded32618cc17c3a42a79da09dd1f0516ceb85103 and https://github.com/graphql/graphql-js/commit/961dab320ba579b8639d218c041b6bd6b7f6664d)
https://github.com/graphql/graphql-js/pull/2223

The behaviour matches graphql-js v15 (v16 removes the indentation inside of block strings: https://github.com/graphql/graphql-js/commit/45e33cefae831a9df2b1a9edebd03a85cdfb33ff)

Ah, I didn't realise symfony/polyfill-php80 is just a transitive dev dependency :/

repo: webonyx/graphql-php


text:
update: 翻译 loaders/restyle-loader.md 内容

翻译完成，原文有 Lorem 占位，似乎是文档未完成。

那我先合并，然后标记此文档为未完成，防止漏下。


text:
refactor: refer to the entry point instead of the first module (module.identifier)

The order of modules can be reordered by optimize-module-order plugins. The intention is to use the entry point as the default identifier, so refer to entries property of the compilation.

Commit 426e758b931fb67d711e25bcf57a5a5ad1c88102 adds a test case.

See also https://github.com/webpack/webpack.js.org/pull/1527.

https://github.com/miraiken/web/commit/46dfdde7694f232115b1d57bea7c0505cca13194 is an easy workaround.

@akihikodaki thanks for PR

@sokra need review

@akihikodaki friendly ping

Issues

Fixes #648

Also fixes https://github.com/webpack/webpack/issues/5733

52a194284a5dfd4c8a1543c82c0cd773ee447978 applies https://github.com/webpack-contrib/extract-text-webpack-plugin/pull/601#pullrequestreview-70527320.

@akihikodaki - Once #652 lands, this will need one more quick rebase before it merges.

@akihikodaki #652 just landed please rebase when time :)

8228819873bba36aded831f5b72e06189ac8c35a: rebased to 5286ab20ad83f6ade30192f939e0b42d3956d6f5.

Module build failed: TypeError: entries[0].identifier is not a function

@akihikodaki Can you revert to compilation.entries[0].identifier ?  Or create a new variable etc ?

f2c3056c25e35e807b74fa208ca50899c0af6708: Reverted the change. I reviewed the intension why I used compilation.entries, and it was actually because entries argument is not an array of the first modules to be executed, but of chunks.

https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/f2c3056c25e35e807b74fa208ca50899c0af6708/src/loader.js#L81 did you add this 🙃 , it seems to be unused ?

No, I didn't.

Thanks! Could someone post here when we get a release bump with this fix?

Is there any plan to release a new version with this fix? The issue with NamedModulesPlugin and HashedModuleIdsPlugin is preventing users from implementing long term caching solution, so it would be nice to get it out.

authors: akihikodaki cletusw d3viant0ne evilebottnawi michael-ciniawsky sgal


text:
publicPath ignored

Hello,
I seem to be having issues serving content when using a publicPath. the devServer serves content from the build directory supplied tocontent in my config, but completely ignores publicPath and so I am unable to server my content correctly.
my config is:
const config = {
        compiler,
        content: [config.get('pathToStaticBuildDir')],
        dev: {
             publicPath: '/client/',
        }
    }

serve(config).then((server) => {})

My build folder contains a folder called client that holds my index.html.
build/
|--client/
|-----index.html

I am expecting to be able to reach this by setting the publicPath. Am I doing something wrong?
Thanks in advance.

Solved myself. thanks

Please don't ignore the issue template next time or your issue will be closed.

authors: shellscape theboyWhoCriedWoolf

repo: webpack-contrib/webpack-serve


text:
Site does not work properly in IE11

Looks like it's broken after update to webpack 5 which transpiles its internals now to es2015 instead of es5. Is this an intentional decision to not support IE 11?

Can you check this preview https://webpack-js-org-git-feature-use-bionic.webpack-docs.vercel.app/ under IE 11? It's a preview right before the upgrade of webpack 5.

Syntax error in another place

Then it might not function well under IE 11 for some time. Feel free to send a PR.

I personally do not use IE11, just noticed it when tested theme switch. If no one complains we can close the issue

@chenxsan Let's use target: ['web', 'es5'] or adding IE11 to browserslist and update webpack to latest (we have bugs)

I'll fix it soon.

I've spent some time tinkering with IE 11 support here https://github.com/webpack/webpack.js.org/pull/4247 but I don't think it will worth it. There're so many packages built without IE 11 support on npm:
          path.resolve(__dirname, 'node_modules/punycode'),
          path.resolve(__dirname, 'node_modules/react-banner'),
          path.resolve(__dirname, 'node_modules/react-tiny-popover')

And there could be more, hence I suggest dropping support for IE 11.

I'm closing this for two reasons:

Internet Explorer 11 desktop application will go out of support and be retired on June 15, 2022 as per https://techcommunity.microsoft.com/t5/windows-it-pro-blog/internet-explorer-11-desktop-app-retirement-faq/ba-p/2366549
We have 0.03% users in the last 30 days using IE

Anyway if anyone want to support it, feel free to file a pull request.

authors: Jokero chenxsan evilebottnawi


text:
Module parse failed: Unexpected character '#' (1:13)

Bug report

What is the current behavior?
When I run: 'npm run build' I get following status:
Webpack
Compiled with some errors in 14.32s
Error: ./.cache/plugins/strapi-plugin-settings-manager/admin/src/components/HeaderNav/styles.scss 1:13
Module parse failed: Unexpected character '#' (1:13)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders'
> $linkcolour: #f5f5f5;
|
| .stmheaderNav {
    at /usr/local/var/www/trip4share-cms/node_modules/strapi-admin/index.js:191:23
    at finalCallback (/usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compiler.js:257:39)
    at /usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compiler.js:273:13
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:22:1)
    at AsyncSeriesHook.lazyCompileHook (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/Hook.js:154:20)
    at onCompiled (/usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compiler.js:271:21)
    at /usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compiler.js:681:15
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/Hook.js:154:20)
    at /usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compiler.js:678:31
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:7:1)
    at AsyncSeriesHook.lazyCompileHook (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/Hook.js:154:20)
    at /usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compilation.js:1423:35
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:7:1)
    at AsyncSeriesHook.lazyCompileHook (/usr/local/var/www/trip4share-cms/node_modules/tapable/lib/Hook.js:154:20)
    at /usr/local/var/www/trip4share-cms/node_modules/webpack/lib/Compilation.js:1414:32
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! trip4share-cms@1.0.0 build: `strapi build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the trip4share-cms@1.0.0 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/Lord-of-the-Mac/.npm/_logs/2020-03-30T21_29_45_998Z-debug.log`

I have cleaned the cache, deleted node_modules however it did not help.
Do you have any idea how to solve it?
Thank you in advance!
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
No parsing error.

Other relevant information:
webpack version:  4.42.1
Node.js version: 12.16.1
Operating System: MacOS Catalina
Additional tools: Strapi.io

Error: ./.cache/plugins/strapi-plugin-settings-manager/admin/src/components/HeaderNav/styles.scss 1:13
Module parse failed: Unexpected character '#' (1:13)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file

Since you're importing scss file, please refer to https://github.com/webpack-contrib/sass-loader document for how to configure it.

Thank you! I had added it in Strapi-Admin folder and it has resolved the problem!

authors: chenxsan wiktort

repo: webpack/webpack


text:
Feature request: 1.13.2

Could not figure out why webpack was not stopping after build, until I realized I still had watch: true in my config.js. I think it would be nice to know if Webpack is running in watch mode, regardless if it was specified by flag or config.
Maybe the following?
"Webpack is now watching entry for changes..."

https://github.com/webpack/webpack/blob/master/bin/webpack.js#L333

authors: colepatrickturner sokra


text:
Another request for require.context(./somedir)

Hi @sokra
With a components directory that looks like this:
A.js
B.js
B.web.js
C.js

And my ComponentLoader that requires it like this:
var ComponentLoader = {
  get: function(name) {
    return require('../components/' + name);
  },
  available: function() {
    var components = require.context('../components').keys();

    return components.map(function(fileName) {
      return fileName.replace('./', '').replace('.js', '');
    });
  }
};

It would be super cool if the context included only
A.js
B.web.js
C.js

in the browser, and
A.js
B.js
C.js

in node.
Currently the context includes all files in the browser and node. (And webpack throws a little error, because B.js includes net.)

@sokra sorry if I'm writing in a so old issue but I'm facing issues with the proposed syntax of the post above.
I thought I could be able to do require.context('.../.../app', name => ['app.js', 'reducers.js', 'routes.js', 'store.js'].indexOf(name) !== -1) to exclude the files listed in the array, but it doesn't seem to work at all.
Am I missing something or this feature has been removed?

I'm with @FezVrasta, is this not supported anymore?

authors: FezVrasta rdrey sontek


text:
SourceMap don't link to an src file but to webpack-internal:///[LINE_NUMBER]

Do you want to request a feature or report a bug? bug

What is the current behavior?
Javascripts errors not link to my source file in the debug console of chrome.
I recently migrate from webpack 1 to 3.

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
Instead of angular.js/10a4:14525 or instead of webpack-internal:///... I should have a link to my source file.
For example here: /src/app/components/series.js
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
This is my webpack config.
return {
    entry: {
        common: "./public/src/app/common.js",
        app: "./public/src/app/app-module.js"
    },
    output: {
        path: __dirname + '/public/dist', //path to where webpack will build your stuff
        publicPath: isBuild ? "/dist/" : "http://" + devDomain + ":" + devPort + "/dist/", //path that will be considered when requiring your files
        filename: "[name].bundle.js"
    },
    resolve: {
        modules: [
            path.join(__dirname, "public/src"),
            "node_modules"
        ]
    },
    devtool: 'cheap-eval-source-map',
    devServer: {
        contentBase: 'public/',
        host: devDomain,
        port: 9000,
        historyApiFallback: true,
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: [
                    path.resolve(__dirname, "node_modules")
                ],
                use: [
                    {
                        loader: 'babel-loader'
                    }
                ]
            },
            {
                test: /\.scss$/,
                exclude: [
                    path.resolve(__dirname, "node_modules")
                ],
                use: isBuild ? ExtractTextPlugin.extract({
                    use: [
                        {loader: 'css-loader', options: {sourceMap: true}},
                        {
                            loader: 'postcss-loader',
                            options: {
                                sourceMap: true,
                                options: postcssConfig
                            }
                        },
                        {loader: 'sass-loader', options: {sourceMap: true}},
                        {
                            loader: 'sass-resources-loader',
                            options: {
                                resources: './public/src/app/styles/variables.scss',
                            },
                        }
                    ]
                }) : [
                    {loader: 'style-loader'},
                    {loader: 'css-loader', options: {sourceMap: true}},
                    {
                        loader: 'postcss-loader',
                        options: {
                            sourceMap: true,
                            options: postcssConfig
                        }
                    },
                    {loader: 'sass-loader', options: {sourceMap: true}},
                    {
                        loader: 'sass-resources-loader',
                        options: {
                            resources: './public/src/app/styles/variables.scss',
                        },
                    }
                ]
            },
            {
                test: /\.css$/,
                use: isBuild ? ExtractTextPlugin.extract('css-loader') :
                    [
                        {loader: 'style-loader'},
                        {loader: 'css-loader', options: {sourceMap: true}},
                    ]
            },
            {
                test: /\.html$/,
                loader: "html-loader"
            },
            {
                test: /\.(png|svg|jpg|gif)$/,
                use: [
                    {
                        loader: 'url-loader',
                        options: {
                            limit: 8192,
                            name: "[hash].[ext]"
                        }
                    }
                ]
            },
            {
                test: /\.(woff|woff2|eot|ttf|otf)$/,
                use: [
                    'file-loader'
                ]
            }
        ],
    },
    plugins: [
        new webpack.ProvidePlugin({
            "window.jQuery": "jquery"
        }),
        new webpack.optimize.CommonsChunkPlugin({
            name: 'common'
        }),
        new ExtractTextPlugin("[name].bundle.css"),
        new webpack.DefinePlugin({
            __PRODUCTION__: env.isprod
        }),
        new webpack.ContextReplacementPlugin(/moment[\/\\]locale$/, /en|fr|ru|es|de/),
        new SWPrecacheWebpackPlugin(SW_PRECACHE_CONFIG),
    ]
}

Stack Traces doesn't handle Source Maps (SourceMaps are handled by browser devtools).

In eval-**-source-map devtools you get a webpack-internal://[module-id]:[line]:[column]. In other devtools you get a url pointing to the bundle file.

get！

authors: FlorianBurgevin Volcano-Yang sokra


text:
fix: Having neither prefix nor suffix in System.import() is okay.

Fixes #2883.

PS: I didn't find any unittests for the context dependency.

@sokra since ContextReplacementPlugin can allow this style of System.import reported, can we modify logic to only throw or warn when there is a truly dynamic import without context? (Which is the scenario I think this warning is preventing)

I would be great to have a test case here!

see issue

authors: TheLarkInn hansl sokra


text:
refactor of ImportContextDependency to es6

What kind of change does this PR introduce?
refactor
Did you add tests for your changes?
current tests should pass
If relevant, link to documentation update:
N/A
Summary
upgrade ImportContextDependency to es6
Does this PR introduce a breaking change?
No

trigger rebuild for travis/appveyor

🎉 The last one of this set. Thank you so much!

authors: TheLarkInn timse


text:
knip gives different results when package is installed vs. npx

In https://github.com/proofcarryingdata/zupass/tree/rob/knip I've added "knip": "npx -y knip --no-gitignore" to the scripts in package.json. Running yarn knip works fine.
knip is not added as a dependency to package.json. If I add it, using yarn add -D knip, this means that the npx command will use the version of knip installed in node_modules, which is what I want (in fact, I can get rid of npx from the script entry, and just have knip --no-gitignore, since yarn will be able to find the binary once the package is installed).
However, when I do this, knip gives different results! In particular, it does not report any unused exports. I can't see why this would be the case.
To reproduce:

Check out the branch mentioned
Run yarn knip and observe that unused exports are listed
Run yarn add -D knip to install knip locally
Run yarn knip and observe that unused exports are not listed

In general you'll want to populate the node_modules folder (i.e. run yarn or npm install) before running Knip, for most issue types. Can't guarantee Knip works well without. Maybe it's some oddity when mixing up yarn with npx? Not sure whether this is an issue with Knip at all? If it work fine with npm then that's usually leading for me.

Good points! I apologize for the slightly confusing issue - I was using npx as an alternative way of running knip without installing the package locally, because having the package installed seems to be what causes it to stop detecting unused exports.
This is a much simpler reproduction, without trying to show the scenario where it works properly via npx without the package installed:

Check out the branch mentioned
Run yarn to install packages
Run yarn knip and observe that unused exports are not listed

I'm seeing unused exports:
$ yarn
yarn install v1.22.19
$ yarn knip
[...]
Unused exports (52)
Container                             apps/consumer-client/src/components/Core.tsx
ExamplePageContainer                  apps/consumer-client/src/components/ExamplePage.tsx
IS_PROD                               apps/consumer-client/src/constants.ts
openZKEdDSAEventTicketPopup           apps/consumer-client/src/pages/pcdpass-examples/zk-eddsa-event-ticket-proof.tsx
openZKEdDSATicketPopup                apps/consumer-client/src/pages/pcdpass-examples/zkeddsa-proof.tsx
RippleLoaderInner                     apps/passport-client/components/core/RippleLoader.tsx
RippleLoaderWrapper                   apps/passport-client/components/core/RippleLoader.tsx
TextEllipsis                          apps/passport-client/components/core/index.tsx
TextSecondary                         apps/passport-client/components/core/index.tsx
Modal                                 apps/passport-client/components/modals/Modal.tsx
HomeScreenImpl                        apps/passport-client/components/screens/HomeScreen.tsx
ArgInput                              apps/passport-client/components/shared/PCDArgs.tsx
ArgTypeLabel                          apps/passport-client/components/shared/PCDArgs.tsx
[...]

So I'm going this issue. Feel free to discuss further or open a new one as necessary.

authors: robknight webpro

repo: webpro/knip

license: ISC


text:
Can't dump DB — MAMP returns 'mysqldump command not found'

MAMP has mysqldump (http://stackoverflow.com/a/3269363) but for some reason, it says the command does not exist.

Solved it with http://ilikekillnerds.com/2014/08/solving-sh-mysql-command-not-found-in-mamp-pro-2-and-mamp-pro-3/

In your home directory create or edit the file “.bash_profile” you can access your home directory by typing: cd ~/
Add this to the top of the file: export PATH=$PATH:/Applications/MAMP/Library/bin
Save the file and then restart your Terminal
In your newly restarted Terminal window type: mysql --version

repo: webrain/grunt-wordpress-deploy


text:
DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version

Since Python 3.12, we have the following DeprecationWarning:
warcio/recordbuilder.py:156: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
    return datetime_to_iso_date(datetime.datetime.utcnow(), use_micros=use_micros)

Pretty easy to fix in 3.12, but maybe not that easy in reality since you probably wanna maintain 2.7+ and 3.4+ support. I suggest to not use what the DeprecationWarning suggests but datetime.datetime.now(tzinfo = datetime.tzinfo.UTC) which should be OK (to be checked).

Tessa @tw4l is working on getting rid of the httpbin version dependency in PR 153 https://github.com/webrecorder/warcio/pull/153 -- and she's setting up Github Actions so we'll have CI again. Once that's done you'll easily be able to finish this one.

Oh great, thank you! I'm glad I stopped before investing too much time in this ^^

Turns out pinning urllib3 to an older version for now resolves it! PR to switch to GitHub Actions CI is now open :) https://github.com/webrecorder/warcio/pull/164

datetime.datetime.now(tzinfo = datetime.tzinfo.UTC) which should be OK (to be checked).

Nope, it will trigger exceptions while doing math with deltatime for code that was relying on the previous (current) behaviour of return naïve datetime, as in warcio.timeutils.timestamp_to_datetime.
Got bitten by it on a custom Filter I wrote on pywb.
My current proposal is to revise all warcio functions returning a datetime and do something like:
def timestamp_to_datetime(string, tzinfo:datetime.timezone=None) -> datetime.datetime:
	#
	# yada yada yada
	#
	return datetime.datetime(year=year,
							 month=month,
							 day=day,
							 hour=hour,
							 minute=minute,
							 second=second,
							 tzinfo=tzinfo)

This way, all current code will still get the expected behaviour, but users willing to cope with 3.12 can just add datetime.timezone.utc to the call and get an aware datetime instead.
Eventually the naive datetime will be fully deprecated in some future Python version. When this happens, changing the function signature to
def timestamp_to_datetime(string, tzinfo:datetime.timezone=datetime.timezone.utc) -> datetime.datetime:

Will "automagically" convert all callers to aware datetime. Code that already coped with the deprecation will not be affected, and code that will break will break in the client's land where the fix will be obvious, and not with some Exception inside warcio that will prompt the client to seek for support.

My current proposal is to revise all warcio functions returning a datetime and do something like:
def timestamp_to_datetime(string, tzinfo:datetime.timezone=None) -> datetime.datetime:
#                                ^^^^^^^ HERE ! ^^^^^^^^^^^^^^^^^
	#
	# yada yada yada
	#
	return datetime.datetime(year=year,
                                                         month=month,
                                                         day=day,
                                                         hour=hour,
                                                         minute=minute,
                                                         second=second,
                                                         tzinfo=tzinfo) # <---- HERE!!!!

Thanks for the suggestion, @Lisias! We went with something similar in the end - a tz_aware arg on the datetime utility functions that is set false by default but can be set true to generate a timezone-aware datetime with tzinfo=datetime.timezone.utc. Since WARC requires dates be in UTC, this felt less error-prone that allowing users to specify any timezone.

repo: webrecorder/warcio


text:
"Uncaught TypeError" in peerconnection calls

Browsers and versions affected
Chrome OS : 62.0.3202.9 / 9901.7.0 dev
Any chrome device
Steps to reproduce

Browse to https://appr.tc/?debug=loopback and join the loopback call
Open the javascript console (alt+cmd+j or ctr+shift+j) and watch for any errors

Expected results
Apprtc loopback call should connect successfully and there should not be any javascript errors
Actual results
Apprtc loopback call connects successfully but javascript logs shows "Uncaught TypeError: Cannot read property '0' of undefined at PeerConnectionClient.onRemoteStreamAdded_ (apprtc.debug.js:4461)"
Loopback_js_logs_M62dev.txt

Note:
This issue is also observed in apprtc peer2peer calls and other webrtc sample pages for peerconnection calls : https://webrtc.github.io/samples/src/content/peerconnection/pc1/, https://webrtc.github.io/samples/src/content/peerconnection/webaudio-input/

@KaptenJansson

I believe this is due to an adapter change, will take a look and see if the web clients need an update or adapter.
FYI @fippo

AppRTC is receiving events from both adapter and Chrome, that's why this is happening.

that does sound familiar... https://bugs.chromium.org/p/chromium/issues/detail?id=761612 ?

bingo. Only happens without experimental web platform features.

I will try to fix the Chromium bug.

Doing pc.addEventListener('track', callback); results in the callback being invoked when ontrack should fire, even though ontrack is behind experimental web platform flags and the flag is off (that's a bug!). Not only does it fire when it shouldn't, because the RTCTrackEvent is behind a flag the event that does fire have undefined track and streams members.

I have a confirmed fix ready, let's wait for it to land and for it to get into canary.

I've confirmed this is fixed on tip of tree. Should be in canary shortly if it isn't already.

authors: KaptenJansson cvranjani fippo henbos

repo: webrtc/apprtc


text:
Failed to get access to local media ( Appr.tc)

Browsers and versions affected
Chromium V60.0.3112.89
OS : Debian Jessie
Hardware : Raspberry Pi 3
Description
Got error Failed to get access to local media ( Appr.tc) while entering chat room at https://appr.tc
Steps to reproduce
Open  https://appr.tc on chromium V60.0.3112.89
Expected results
Video call working without any error,
Actual results
Got error Failed to get access to local media , and can't stream local video

Please include javascript logs. What camera do you have?

I've got the same issue with USB camera Logitech HD Pro Webcam C920
Browsers and versions affected
Chromium V60.0.3112.89
OS : Debian Strecht
Hardware : Raspberry Pi 3
Description
Got error Failed to get access to local media ( Appr.tc) while entering chat room at https://appr.tc
Steps to reproduce
Open https://appr.tc on chromium V60.0.3112.89
Expected results
Video call working without any error,
Actual results
Got error Failed to get access to local media , and can't stream local video

authors: KaptenJansson VietPham87 barcristian


text:
Webview not setting Origin header required by CORS

What OS are you using (uname -a, or Windows version)?
Darwin Kernel Version 17.7.0: ; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
What programming language are you using (C/C++/Go/Rust)?
go version go1.12 darwin/amd64
What did you expect to see and what you saw instead?
Using the network tab in the inspector I am seeing that the Origin header is not being set on requests. From https://www.html5rocks.com/en/tutorials/cors/ (emphasis theirs):

"The first thing to note is that a valid CORS request always contains an Origin header."

I am not a front-end developer so I am not 100% sure this is why cross-origin is failing, but I think it might be.  See attached screenshots:

I wish I had the skill to submit a pull request to (try to) fix it, but C++ it out of my league, at least for the foreseeable future.

If you're on OSX, add this to webview.h:1876:
class_replaceProperty(__WKPreferences, "webSecurityEnabled", attrs, 2);
objc_registerClassPair(__WKPreferences);
objc_msgSend(wkPref, sel_registerName("setValue:forKey:"),
             objc_msgSend((id)objc_getClass("NSNumber"),
                          sel_registerName("numberWithBool:"), false),
             objc_msgSend((id)objc_getClass("NSString"),
                          sel_registerName("stringWithUTF8String:"),
                          "webSecurityEnabled"));

I've been researching all day, and I believe this is what is need to make CORS requests on Linux for http and https requests. Unfortunately, it's not working and I don't know why. This can be inserted in webview.h:338:
WebKitWebContext *wc = webkit_web_view_get_context(WEBKIT_WEB_VIEW(w->priv.webview));
WebKitSecurityManager *sm = webkit_web_context_get_security_manager(wc);
webkit_security_manager_register_uri_scheme_as_cors_enabled(sm, "http");
webkit_security_manager_register_uri_scheme_as_cors_enabled(sm, "https");

If anyone can point out what I'm missing or if I'm barking up the wrong tree, ping me with a solution or some advice.

Any luck with this @drew-wallace

Unfortunately, I don't think it's possible. There's no API for disabling security which is what needs to be done to do CORS. I ended up making a tiny web server within my app to forward/proxy all requests through.

If you're on OSX, add this to webview.h:1876:

class_replaceProperty(__WKPreferences, "webSecurityEnabled", attrs, 2);

objc_registerClassPair(__WKPreferences);

objc_msgSend(wkPref, sel_registerName("setValue:forKey:"),

             objc_msgSend((id)objc_getClass("NSNumber"),

                          sel_registerName("numberWithBool:"), false),

             objc_msgSend((id)objc_getClass("NSString"),

                          sel_registerName("stringWithUTF8String:"),

                          "webSecurityEnabled"));

cool！

I'm going to assume this is no longer relevant. Disabling security features probably isn't the right approach here, anyway:

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources

From: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS (emphasis mine)
CORS headers are set by the server and not the webview library. Browser engines do restrict resource loading via CSP and other security mechanisms. If someone wants to disable them, I'd suggest opening a discussion first so we can consider alternatives.

repo: webview/webview


text:
微信授权按钮绑定到UGUI位置有偏差

想法是先获取按钮在屏幕空间的坐标，再转换到微信的屏幕空间坐标，然后创建UserInfoButton
代码如下：
public class UiToScreenPos
    {
        public static Vector2 GetUGUIForScreenPos(Vector3 targetWorldPos)
        {
           Vector2 screenPoint = RectTransformUtility.WorldToScreenPoint(Camera.main, targetWorldPos);
           screenPoint.y = Screen.height - screenPoint.y;
           return screenPoint;
        }
    }

void Start()
        {
            WX.InitSDK(x=>Debug.Log("微信SDK初始化完成！"));
            foreach (var btn in btns)
            {
                RectTransform rect = btn.GetComponent<RectTransform>();
                Vector2 pos = UiToScreenPos.GetUGUIForScreenPos(rect.position);
                WX.CreateUserInfoButton((int)pos.x, (int)pos.y, (int)rect.sizeDelta.x, (int)rect.sizeDelta.y, "zh_CN", true);
            }
        }

实际上位置会有偏差，请问有没有什么好的解决方案？

找到原因了，是因为SDK的CreateUserInfoButton传的是按钮左上角的坐标，然后Unity的屏幕空间坐标跟微信的屏幕空间坐标也不一样，需要转换。
修改后的代码如下：
void Start()
        {
            WX.InitSDK(x=>Debug.Log("微信SDK初始化完成！"));
            foreach (var btn in btns)
            {
                RectTransform rect = btn.GetComponent<RectTransform>();
                Vector2 pos = UiToScreenPos.GetUGUIForScreenPos(rect.position);
                WX.CreateUserInfoButton((int)(pos.x-rect.sizeDelta.x/2), (int)(pos.y-rect.sizeDelta.y/2), (int)rect.sizeDelta.x, (int)rect.sizeDelta.y, "zh_CN", true);
            }
        }

已经解决。


text:
完全不知道怎么用

完全不知道怎么用。
直接小程序引入examples 无法正常使用，构建无法构建，文档能不能详细点？

examples 添加了文档说明，按照里面步骤应该就可以运行。 https://github.com/wechat-miniprogram/miniprogram-i18n/blob/master/examples/README.md


text:
退款结果通知API返回值没有对应的结构

Go 版本：
wechatpay-go 版本：v0.21.38

可行的处理请参考下 #103 。
现状是，退款实体的属性 status 在退款结果通知中被定义成 refund_status 了，所以自动生成的 models.go 中没有退款结果通知的结构。
还有一个解决方案是，复制并修改一个退款结果通知结构，放在 models_ext.go 中，避免跟自动生成的 models 冲突。
@chyileon 是否可以解决你的问题？ 我们更欢迎 Pull Request。

authors: chyileon xy-peng


text:
2020-04-10-seminar-minutes-2020-06

update
update
[ImgBot] Optimize images
*Total -- 1,880.18kb -> 1,794.03kb (4.58%)
/docs/assets/2020/seminar-02/talk-aili.jpg -- 493.62kb -> 469.07kb (4.97%)
/docs/assets/2020/seminar-02/group-photo.jpg -- 338.18kb -> 321.94kb (4.8%)
/docs/assets/2020/seminar-02/chairs.jpg -- 502.18kb -> 480.25kb (4.37%)
/docs/assets/2020/seminar-02/talk-xiaomei.jpg -- 546.19kb -> 522.77kb (4.29%)
Signed-off-by: ImgBotApp ImgBotHelp@gmail.com

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

There's some CI issues that need to be fixed before merge this PR.
https://travis-ci.com/github/wechaty/bot5.club/builds/160539083
If you want, I can help you to fix that
However, I saw that this PR includes two unrelated changes of two photos of the second seminar of this year, Could you please remove that? Or does that changes on purpose?
Looking forward to your reply, and thank you very much!

authors: CLAassistant Xiaomei-Zhang huan


text:
登录失败: PuppetWeChatBridge readyAngular() exception: TimeoutError: waiting for function failed: timeout 30000ms exceeded

操作系统： MacOS 11.6.1
NodeJS: v16.13.1
设置环境变量
export WECHATY_LOG=verbose
export WECHATY_PUPPET=wechaty-puppet-wechat
启动
npm start
报错日志
11:37:44 VERB PuppetWeChatEvent onScan({code: 201, url: https://login.weixin.qq.com/qrcode/odsv5ChIGQ==})
11:37:44 VERB StateSwitch <WechatyReady> inactive(true) <- (true)
11:37:44 INFO StarterBot onScan: Scanned(3)
11:37:48 VERB PuppetWeChatBridge onLoad() page.url=https://wx2.qq.com/cgi-bin/mmwebwx-bin/webwxnewloginpage?ticket=Azgh72H3h7wI7cdoHmPzM_9K@qrticket_0&uuid=odsv5ChIGQ==&lang=en_US&scan=1641267463
11:37:48 VERB PuppetWeChatBridge readyAngular()
11:38:18 VERB PuppetWeChatBridge readyAngular() exception: TimeoutError: waiting for function failed: timeout 30000ms exceeded
11:38:18 VERB PuppetWeChatBridge testBlockedMessage(<pre style="word-wrap: break-word; white-space: pr)
11:38:18 VERB PuppetWeChatBridge preHtmlToXml()
11:38:18 WARN PuppetWeChatBridge testBlockedMessage() error.ret=1203
11:38:18 INFO PuppetWeChatBridge

        Please see: Account Login Issue <https://github.com/wechaty/wechaty/issues/872>

11:38:18 ERR PuppetWeChatBridge onLoad() exception: Error: 登录失败。
11:38:18 ERR Config ###########################
11:38:18 ERR Config Wechaty unhandledRejection: Error: 登录失败。
    at Bridge.readyAngular (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:324:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:212:7) [object Promise]
11:38:18 ERR Config ###########################
11:38:18 ERR Config process.on(unhandledRejection) promise.catch(登录失败。)
Config GError: 登录失败。
    at Bridge.readyAngular (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:324:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:212:7) {
  code: 2,
  details: 'Error: 登录失败。\n' +
    '    at Bridge.readyAngular (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:324:15)\n' +
    '    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n' +
    '    at async Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:212:7)'
}
11:38:44 WARN PuppetWatchdogAgent start() reset() reason: {"data":{"code":201,"url":"https://login.weixin.qq.com/qrcode/odsv5ChIGQ=="},"type":"scan","timeoutMilliseconds":60000}
11:38:44 ERR Config ###########################
11:38:44 ERR Config Wechaty uncaughtException: Error: WatchdogAgent reset: lastFood: "{"data":{"code":201,"url":"https://login.weixin.qq.com/qrcode/odsv5ChIGQ=="},"type":"scan","timeoutMilliseconds":60000}"
    at Watchdog.reset (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet/src/agents/watchdog-agent.ts:65:33)
    at Watchdog.emit (node:events:390:28)
    at Watchdog.emit (node:domain:475:12)
    at Timeout._onTimeout (file:///Users/admin/project/github/wechaty-getting-started/node_modules/watchdog/src/watchdog.ts:115:12)
    at listOnTimeout (node:internal/timers:557:17)
    at processTimers (node:internal/timers:500:7) uncaughtException
11:38:44 ERR Config ###########################
11:39:44 WARN PuppetWeChat initScanWatchdog() on(reset) lastFood: [object Object], timePast: 120000
11:39:44 VERB PuppetWeChatBridge reload()
11:39:44 ERR PuppetWeChat initScanWatchdog() on(reset) exception: Error: Protocol error (Page.reload): Session closed. Most likely the page has been closed.
11:39:44 ERR PuppetWeChat initScanWatchdog() on(reset) try to recover by bridge.{quit,init}()
11:39:44 VERB PuppetWeChatBridge stop()
11:39:44 VERB StateSwitch <PuppetWeChatBridge> inactive(pending) <- (false)
11:39:44 WARN PuppetWeChatBridge stop() page.close() exception: Error: Protocol error: Connection closed. Most likely the page has been closed.
11:39:44 VERB StateSwitch <PuppetWeChatBridge> inactive(true) <- (pending)
11:39:44 VERB PuppetWeChatBridge start()
11:39:44 VERB StateSwitch <PuppetWeChatBridge> active(pending) <- (false)
11:39:44 VERB PuppetWeChatBridge initBrowser()
11:39:44 VERB PuppetWeChatBridge initBrowser() with options={"args":["--audio-output-channels=0","--disable-default-apps","--disable-translate","--disable-gpu","--disable-setuid-sandbox","--disable-sync","--hide-scrollbars","--mute-audio","--no-sandbox"],"headless":true}
11:39:44 VERB PuppetWeChatBridge initBrowser() version: HeadlessChrome/93.0.4577.0
11:39:44 VERB PuppetWeChatBridge start() initBrowser() done
11:39:44 VERB PuppetWeChatBridge initPage()
11:39:45 VERB PuppetWeChatBridge cookieDomain([object Object],[object Object],[object Object])
11:39:45 VERB PuppetWeChatBridge initPage() before page.goto(url)
11:39:47 VERB PuppetWeChatBridge initPage() after page.goto(url)
11:39:48 VERB PuppetWeChatBridge onLoad() page.url=https://wx.qq.com/?target=t
11:39:48 VERB PuppetWeChatBridge onLoad() page.url=https://wx.qq.com/?target=t
11:39:48 ERR PuppetWeChatBridge onLoad() exception: Error: Failed to add page binding with name wechatyPuppetBridgeEmit: window['wechatyPuppetBridgeEmit'] already exists!
11:39:48 ERR PuppetWeChatBridge onLoad() exception: ProtocolError: Protocol error (Page.addScriptToEvaluateOnNewDocument): Target closed.
11:39:48 ERR Config ###########################
11:39:48 ERR Config Wechaty unhandledRejection: Error: Protocol error: Connection closed. Most likely the page has been closed.
    at assert (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/assert.ts:23:21)
    at Page.close (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:2922:11)
    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:220:18)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) [object Promise]
11:39:48 ERR Config ###########################
11:39:48 ERR Config process.on(unhandledRejection) promise.catch(Protocol error: Connection closed. Most likely the page has been closed.)
Config GError: Protocol error: Connection closed. Most likely the page has been closed.
    at assert (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/assert.ts:23:21)
    at Page.close (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:2922:11)
    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:220:18)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  code: 2,
  details: 'Error: Protocol error: Connection closed. Most likely the page has been closed.\n' +
    '    at assert (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/assert.ts:23:21)\n' +
    '    at Page.close (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:2922:11)\n' +
    '    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:220:18)\n' +
    '    at processTicksAndRejections (node:internal/process/task_queues:96:5)'
}
11:39:48 ERR Config ###########################
11:39:48 ERR Config Wechaty unhandledRejection: Error: Failed to add page binding with name wechatyPuppetBridgeEmit: window['wechatyPuppetBridgeEmit'] already exists!
    at Page.exposeFunction (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:1393:13)
    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:209:20)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) [object Promise]
11:39:48 ERR Config ###########################
11:39:48 ERR Config process.on(unhandledRejection) promise.catch(Failed to add page binding with name wechatyPuppetBridgeEmit: window['wechatyPuppetBridgeEmit'] already exists!)
Config GError: Failed to add page binding with name wechatyPuppetBridgeEmit: window['wechatyPuppetBridgeEmit'] already exists!
    at Page.exposeFunction (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:1393:13)
    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:209:20)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  code: 2,
  details: "Error: Failed to add page binding with name wechatyPuppetBridgeEmit: window['wechatyPuppetBridgeEmit'] already exists!\n" +
    '    at Page.exposeFunction (/Users/admin/project/github/wechaty-getting-started/node_modules/puppeteer/src/common/Page.ts:1393:13)\n' +
    '    at Bridge.onLoad (file:///Users/admin/project/github/wechaty-getting-started/node_modules/wechaty-puppet-wechat/src/bridge.ts:209:20)\n' +
    '    at processTicksAndRejections (node:internal/process/task_queues:96:5)'
}

Same issue here. I was able to log in last week, but it failed today.

Looks like it's the same issue here: https://github.com/wechaty/puppet-wechat/issues/192

repo: wechaty/getting-started


text:
在timeout执行后， pendingLogoutEmitTimer没有清除

https://github.com/wechaty/puppet-whatsapp/blob/ee0cd9ff48c42df14ae9d20c75e19c1b212a3cc7/src/manager.ts#L548-L571
在timeout执行后，this. pendingLogoutEmitTimer的值依然存在，导致新的login事件无法触发，状态维护错误。
15:35:46 VERB ConfigManager receive maintain mode heartbeat.
15:36:03 INFO PuppetWhatsApp Manager onChangeState("TIMEOUT")
15:36:06 INFO PuppetWhatsApp onLogout(8618500946096@c.us, 手机端网络连接异常)
15:36:06 INFO PuppetWhatsApp LOGOUT, 8618500946096@c.us
15:36:06 INFO BOT LOGOUT: Contact<MyOnlyStarCN> logout(手机端网络连接异常)
15:36:06 INFO Broadcast stopAllBroadcast()
15:36:06 INFO MessageSender clearForwardCache()
[2022-02-17T15:36:06.537] [WARN] main-1645082767249-amqp-connect-channel - Killed Consumer normalConsumer
[2022-02-17T15:36:06.764] [WARN] main-1645082767249-amqp-connect-channel - Killed Consumer priorityConsumer
15:36:56 VERB ConfigManager receive maintain mode heartbeat.
15:37:29 INFO PuppetWhatsApp Manager onChangeState("CONNECTED")
15:37:29 VERB FlashStore get(120363022968200999@g.us)

fixed in https://github.com/wechaty/puppet-whatsapp/pull/229

repo: wechaty/puppet-whatsapp


text:
roomJoinFailed

#248

Coverage increased (+0.7%) to 56.518% when pulling 08918810fc5b20b3212063b2a3b2a855ae90f5b8 on lijiarui:roomJoinFailed into 7faecd62ea4fa89a0840af78ad5ce11393d82f63 on wechaty:master.

authors: coveralls lijiarui

repo: wechaty/wechaty


text:
Take over maintenance?

I see that you've been very active updating surveyor_gui and I no longer have a need for it and have been strapped for time to update it.  Would you like to become the official maintainer or, alternatively, I could direct people to your branch?

Hi Kjayma --
So sorry about the PRs.  I forked your repo when I clearly should have cloned it.
Although I'm not quite ready to fully support my changes, If you want to point people here for now, I can try to help them out.
Then hopefully in a month or so I can polish the changes to my version and then folks can start using it.

OK - If you want to re-open the pull request, I'll try to take a look
either this weekend or next.
On Wed, Apr 26, 2017 at 9:58 PM, Ashley Engelund notifications@github.com
wrote:

Hi Kjayma --
So sorry about the PRs. I forked your repo when I clearly should have
cloned it.
Although I'm not quite ready to fully support my changes, If you want to
point people here for now, I can try to help them out.
Then hopefully in a month or so I can polish the changes to my version and
then folks can start using it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/weedySeaDragon/surveyor_gui/issues/10#issuecomment-297590025,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAiSwIGU6uZrxU7OSZgQWbiI3ZkxerW4ks5rz_ZegaJpZM4NJUOa
.

You can (and should) ignore the PRs.  I should never have pushed them to your repo -- I should have only created them against mine.  (If I had cloned your repo instead of forking it, that wouldn't have happened.)  I was working too fast and didn't pay attention to the fact that my PRs were going to be created against your repo.  Sorry!
And thanks for your work on surveryor_gui!

authors: kjayma weedySeaDragon


text:
🛑 Deriw Trade is down

In 0ce2011, Deriw Trade (https://www.deriw.com/trade/WBTC-USDT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Deriw Trade is back up in 723c0db after 21 minutes.


text:
support for webpack V4

webpack4 don't support this.option in loader source code any more.

+1
Seems there is a hard-coded usage of options
Tried Webpack 4 and getting Cannot read property 'vue' of undefined at ...weex-vue-loader/lib/loader.js:60:78

please fix it

authors: Jevirs lerit n3ps

repo: weexteam/weex-vue-loader


text:
Could not find com.alibaba:fastjson:1.1.27-android

The annotationProcessor 'com.taobao.android:weexplugin-processor:1.3' dependencies on com.alibaba:fastjson:1.1.27-android, but "Could not find com.alibaba:fastjson:1.1.27-android."

Environment
➜ weex --version
 - weexpack : v1.2.3
 - weex-builder : v0.4.0
 - weex-previewer : v1.5.1

Description
➜ weex plugin create my-weex-plugin
➜ cd my-weex-plugin
// open ./playground/android  with android studio3.0

when building gradle and get Error:Failed to resolve: com.alibaba:fastjson:1.1.27-android

In fact  after searching the maven repository,  the 'com.taobao.android:weexplugin-processor:1.3' depends on the 'com.alibaba:fastjson:1.1.27-android' which does not exist. I have to remove this process or from build.gradle and then the project got compiled successfully. But I not sure if the weex will work as expected.  Just wonder,  is the weex project totally dead or just dead for opensource project?

issue can not be reproduced, could you please run command 'weex platform list', and check the 'Installed platforms' items, the version should be android 6.3.17. If that, you can find that already import fastjson v1.1.46

@myeveryheart

➜  awesome-app weex platform list
Installed platforms:

Available platforms:
- android ^6.3.8
  - ios ^4.1.6

cann't run weex platform list in weex plugin project( create by weex plugin create my-weex-plugin )
But I get this error in weex plugin project.

Maybe @tralves can answer @huangminlinux 's questions, I have tested the template on my platform, it works ok for me.

Could not find com.alibaba:fastjson:1.1.27-android.
Searched in the following locations:
file:/Users/xxx/Library/Android/sdk/extras/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
file:/Users/xxx/Library/Android/sdk/extras/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
file:/Users/xxx/Library/Android/sdk/extras/google/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
file:/Users/xxx/Library/Android/sdk/extras/google/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
file:/Users/xxx/Library/Android/sdk/extras/android/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
file:/Users/xxx/Library/Android/sdk/extras/android/m2repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
file:/Users/xxx/.m2/repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
file:/Users/xxx/.m2/repository/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
https://jcenter.bintray.com/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
https://jcenter.bintray.com/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
https://repo.maven.apache.org/maven2/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
https://repo.maven.apache.org/maven2/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
https://maven.google.com/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.pom
https://maven.google.com/com/alibaba/fastjson/1.1.27-android/fastjson-1.1.27-android.jar
Required by:
project :app > com.taobao.android:weexplugin-processor:1.3
download pom、jar file,  and put them in your local file can fix it
https://yun.baidu.com/share/link?shareid=4294337343&uk=1561289668&fid=393924576692924
https://repo.maven.apache.org/maven2/com/alibaba/fastjson/1.1.27/fastjson-1.1.27.pom

Can I remove this dependency from my build.gradle?
I find com.alibaba:fastjson:1.2.41 is in our private maven repository, so when I replace com.alibaba:fastjson:1.2.41.android by com.alibaba:fastjson:1.2.41, I didn't get any error, but I'm not sure does it correctly? Anyone could tell the different between com.alibaba:fastjson:1.2.41.android with com.alibaba:fastjson:1.2.41?

authors: baivoom erha19 huangminlinux myeveryheart olivercm soaringEveryday thirtyyuan

repo: weexteam/weexpack-android


text:
Refactor VueI18n creation to own module

This refactors the creation of the VueI18n instance by encapsulating it in an own ES module. So the i18n instance can be imported to other pure ES modules and will allow internationalization there.
This follows the approach given here: https://github.com/kazupon/vue-i18n/issues/149#issuecomment-357455921
This would make the introduction of a global $appLanguage variable in #356  obsolete by this much cleaner and more versatile approach. If you approve this PR, I'd happily revert #356 afterwards in a separate PR.
Accessing the current app language in pure ES modules could then be done by the following code:
const { i18n } = await import('../../../src/locales/wgu-i18n.js');
console.log(i18n.locale);

Thanks for your review @sronveaux and thanks for your suggestion regarding the assignment to Vue.prototype in the tests. I created an issue to improve that as a whole :arrow_right: #388. Going to merge now...

repo: wegue-oss/wegue


text:
Mark as required

It would be great if we could have a decorator that allowed use to mark a paramater as required during serialize/deserialize/auto
This would allow us to ensure that the contract is properly met.

How would imagine this plays out?
class Thing {
   @autoseralizeAs(String, true) thing1 : string;
   //or
   @autoserializeRequired thing2 : string;

}

or something else? I like the idea, I'm unsure off the top of my head what the interface for that would look like

I prefer
@autoseralizeAs(String, true) thing1 : string;
Like java style
@autoseralizeAs(columnDefinition="string", required=true)

or even just a seperate annotation
@required
@autoserialize
or require all and then opt out
@requireAll
export class Foo {
@autoserialize thing1
@autoserialize thing2
@autoserialize thing3
@autoserialize thing4
@optional
@autoserialize thing5
}

Because interfaces are compile time only in typescript - i see a lot of 'loose' declarations where data could or could not be missing depending on the source.
Having auto runtime checking of all properties would be a huge win

Yeah I agree. I think I prefer the separate annotation. I'll see what I can do about that, or feel free to submit a PR since it will take me a few days before I have time to look at this seriously

Happy to test it when its ready! I definitely dont have the bandwidth

Any news on the proposal?
This would allow me to drop all my PropTypes (React) that I'm still keeping for the runtime checks

No no update yet, haven't had the time unfortunately. feel free to submit a PR though

authors: Marche86 hwaterke rightisleft weichx

repo: weichx/cerialize


text:
lower evaluation metrics using your trained models in google drive?

Hi, I used your trained model, ground truth pose and depth files to calculate the "abs rel", "abs diff", .... But they are much lower than DPSNet (the last table of DPSNet code, https://github.com/sunghoonim/DPSNet).
Metrics
'abs_rel', 'abs_diff', 'sq_rel', 'rms', 'log_rms', 'a1', 'a2', 'a3'
MVS
DPSNet    | 0.0722 0.2095 0.0798 0.4928 0.1527 0.8930 0.9502 0.9760
DeepSFM | 0.0986,0.7810,0.2797,2.1187,0.1470,0.8889,0.9774,0.9916
Sun3D
DPSNet    | 0.1470 0.3234 0.1071 0.4269 0.1906 0.7892 0.9317 0.9672
DeepSFM | 0.0723,0.9464,0.2570,1.4316,0.1049,0.9598,0.9887,0.9942
RGBD
DPSNet    | 0.1538 0.5235 0.2149 0.7226 0.2263 0.7842 0.8959 0.9402
DeepSFM | 0.1353,3.8738,2.2566,18.1695,0.2085,0.8909,0.9722,0.9836
Scenes
DPSNet   | 0.0558 0.2430 0.1435 0.7136 0.1396 0.9502 0.9726 0.9804
DeepSFM | 0.0668,1.0298,0.2532,1.9122,0.1057,0.9621,0.9906,0.9961
I used ground truth poses.txt and *.npy depth files, which should give a better performance.
But from the above comparison, I found in the first 5 metrics (lower better), at most cases, DeepSFM is worse than DPS, especially DeepSFM on RGBD.
This seems a bit wired.
Is there any issues about this problem or could you give me some tips as I may miss something?

Thanks, our depth-subnet pretrained model is trained with estimated pose and depth initializations, since the task is to estimate depth and pose without gt camera motion, and the results are not consistently better than DPSNet which trained with GT pose. Meanwhile, in my experiments, I found that the Abs diff  Sq_Rel  and RMSE are very sensitive metrics.

got it, thank you.

@zwxu064 @weixk2015    hello , I think you have reproduced the paper .It seems because the initial posture data from demon is quite different from pose.txt , so my evaluation  results are very different from the paper. After inspection , I don't know why and how to do? I get these initial poses which are obtained by running the example.py file in the demon with given two photos. Could  you share how you obtained the initial poses from the demon and the level of difference between them and pose.txt? thanks  very much