[BUG][Potential] server up for a while and then panic

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

DeepFlow Component
Server
What you expected to happen
When deploying the self-builded DeepFlow server, it ran into panic after a few seconds. It MIGHT caused by the existing issue in main branch but I cannot locate the root cause.
I am trying to post the log here and see if it could be reproduced by other developers.
Kubernetes log I got:
2023-08-16 16:37:31.129 [INFO] [trisolaris/synchronize] tsdb.go:64 ctrl_ip is <IP_ADDRESS>, (platform data version<PHONE_NUMBER> -> 0), (acl version<PHONE_NUMBER> -> 0), (groups version<PHONE_NUMBER> -> 0), NAME:server-pod-names-watcher
2023-08-16 16:37:31.141 [INFO] [clickhouse.client] client.go:197 query_uuid: a638e9f1-822e-434e-b481-0492fc696c47. query api statistics: 0 rows, 2 columns, 0 bytes, cost 1.000000 ms
2023-08-16 16:37:31.142 [INFO] [clickhouse.client] client.go:197 query_uuid: a638e9f1-822e-434e-b481-0492fc696c47. query api statistics: 0 rows, 2 columns, 0 bytes, cost 0.000000 ms
2023-08-16 16:37:31.143 [INFO] [clickhouse.client] client.go:197 query_uuid: a638e9f1-822e-434e-b481-0492fc696c47. query api statistics: 0 rows, 3 columns, 0 bytes, cost 0.000000 ms
2023-08-16 16:37:31.405 [INFO] [trisolaris/synchronize] tsdb.go:64 ctrl_ip is <IP_ADDRESS>, (platform data version<PHONE_NUMBER> -><PHONE_NUMBER>), (acl version<PHONE_NUMBER> -> 0), (groups version<PHONE_NUMBER> -><PHONE_NUMBER>), NAME:ingester
2023-08-16 16:37:31.405 [INFO] [trisolaris/synchronize] tsdb.go:75 ctrl_ip:<IP_ADDRESS>, cpu_num:16, memory_size:33347633152, arch:x86_64, os:alpine 3.18.3, kernel_version:5.15.0, pcap_data_mount_path:<nil>
2023-08-16 16:37:32.118 [INFO] [trisolaris/synchronize] tsdb.go:64 ctrl_ip is <IP_ADDRESS>, (platform data version<PHONE_NUMBER> -> 0), (acl version<PHONE_NUMBER> -> 0), (groups version<PHONE_NUMBER> -> 0), NAME:resource-info-watcher
2023-08-16 16:37:32.118 [INFO] [event.decoder] grpc_resource_info.go:156 Event update rpc platformdata version 0 -><PHONE_NUMBER>
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0xa92dac]

goroutine 2683 [running]:
github.com/deepflowio/deepflow/message/trident.(*PrometheusTargetResponse).MarshalToSizedBuffer(0x0, {0x9bc5780, 0x0, 0x0})
	/home/jiekun/repo/github.com/deepflow/server/vendor/github.com/deepflowio/deepflow/message/trident/trident.pb.go:13659 +0x2c
github.com/deepflowio/deepflow/message/trident.(*PrometheusTargetResponse).Marshal(0x0?)
	/home/jiekun/repo/github.com/deepflow/server/vendor/github.com/deepflowio/deepflow/message/trident/trident.pb.go:13646 +0x56
google.golang.org/protobuf/internal/impl.legacyMarshal({{}, {0x5cf4230, 0xc05ee98070}, {0x0, 0x0, 0x0}, 0x0})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/protobuf/internal/impl/legacy_message.go:402 +0xa2
google.golang.org/protobuf/proto.MarshalOptions.marshal({{}, 0xb8?, 0x0, 0x0}, {0x0, 0x0, 0x0}, {0x5cf4230, 0xc05ee98070})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/protobuf/proto/encode.go:166 +0x27b
google.golang.org/protobuf/proto.MarshalOptions.MarshalAppend({{}, 0xa0?, 0x4b?, 0xe7?}, {0x0, 0x0, 0x0}, {0x5c6c860?, 0xc05ee98070?})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/protobuf/proto/encode.go:125 +0x79
github.com/golang/protobuf/proto.marshalAppend({0x0, 0x0, 0x0}, {0x5c9ae80?, 0x0?}, 0x80?)
	/home/jiekun/repo/github.com/deepflow/server/vendor/github.com/golang/protobuf/proto/wire.go:40 +0xa5
github.com/golang/protobuf/proto.Marshal(...)
	/home/jiekun/repo/github.com/deepflow/server/vendor/github.com/golang/protobuf/proto/wire.go:23
google.golang.org/grpc/encoding/proto.codec.Marshal({}, {0x4e74ba0, 0x0})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/encoding/proto/proto.go:45 +0x4e
google.golang.org/grpc.encode({0x7fa6e1a6cf98?, 0x9bc5780?}, {0x4e74ba0?, 0x0?})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/rpc_util.go:596 +0x44
google.golang.org/grpc.(*Server).sendResponse(0xc005095c20, {0x5ce4960, 0xc000007a00}, 0xc05ee96000, {0x4e74ba0?, 0x0}, {0x0, 0x0}, 0x0?, {0x0, ...})
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/server.go:1107 +0x1b4
google.golang.org/grpc.(*Server).processUnaryRPC(0xc005095c20, {0x5ce4960, 0xc000007a00}, 0xc05ee96000, 0xc0019be960, 0x93a0330, 0x0)
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/server.go:1378 +0xde9
google.golang.org/grpc.(*Server).handleStream(0xc005095c20, {0x5ce4960, 0xc000007a00}, 0xc05ee96000, 0x0)
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/server.go:1704 +0xa2f
google.golang.org/grpc.(*Server).serveStreams.func1.2()
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/server.go:965 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
	/home/jiekun/repo/github.com/deepflow/server/vendor/google.golang.org/grpc/server.go:963 +0x28a

How to reproduce

build with main branch (e316d1d0f2f86a7d0b4f13c08d7bfa5d7f4c1528).

cd server
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 make -e BINARY_SUFFIX=.amd64

build a docker image.

docker build --network host -t deepflow-ce:dev.v1.0.0 .

load the image into my minikube (It might not be necessary. Maybe you could try it with public image registry and jump to step-4).

minikube image load deepflow-ce:dev.v1.0.0

update deepflow-server deployment.

kubectl edit deployment/deepflow-server

I have the following fields edited:
      ...
      containers:
        - name: deepflow-server
          # before
          image: registry.cn-hongkong.aliyuncs.com/deepflow-ce/deepflow-server:v6.3.5
          # after
          image: deepflow-ce:dev.v1.0.0
          ...

          # before
          imagePullPolicy: Always
          # after
          imagePullPolicy: Never
      ...

The server went up for a while, I can query and see the graph on Grafana. But then it crashed and I got the panic log above.
I repeat the steps above with tag v6.3.5 and everything looks fine (for at least couple hours).
DeepFlow version
➜  deepflow kubectl exec -it -n deepflow deploy/deepflow-server -- deepflow-server -v
2023/08/16 17:58:23 ENV K8S_NODE_NAME_FOR_DEEPFLOW=minikube; K8S_NODE_IP_FOR_DEEPFLOW=<IP_ADDRESS>; K8S_POD_NAME_FOR_DEEPFLOW=deepflow-server-859b488549-5fkfn; K8S_POD_IP_FOR_DEEPFLOW=<IP_ADDRESS>; K8S_NAMESPACE_FOR_DEEPFLOW=deepflow
Name: deepflow-server community edition
Branch:
CommitID: fc3c665be05c57d02b75a216cb6e81b4dd285bcd
RevCount: 8721
Compiler: go version go1.19 linux/amd64
CompileTime: 2023-08-16 16:47:25

➜  deepflow kubectl exec -it -n deepflow ds/deepflow-agent -- deepflow-agent -v
Defaulted container "deepflow-agent" out of: deepflow-agent, configure-sysctl (init)
8721-fc3c665be05c57d02b75a216cb6e81b4dd285bcd
Name: deepflow-agent community edition
Branch: v6.3.5
CommitId: fc3c665be05c57d02b75a216cb6e81b4dd285bcd
RevCount: 8721
Compiler: rustc 1.71.0 (8ede3aae2 2023-07-12)
CompileTime: 2023-08-11 06:58:09

DeepFlow agent list
N/A
Kubernetes CNI
N/A
Operation-System/Kernel version
➜  deepflow awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release
"Ubuntu 20.04.6 LTS"
➜  deepflow uname -r
5.15.0-78-generic

Anything else
In order to try DeepFlow, I have OTel demo deployed.
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install my-otel-demo open-telemetry/opentelemetry-demo

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

latest fixed


I have a new whatsapp phone number and Franz is no longer responding to my phone for whatsapp

I have a new phone number associated with my whatsapp and franz whatsapp client is no longer responding to my phone.  Any tips greatly appreciated

Expected Behavior

Current Behavior

Screenshots (if appropriate):
Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Franz Version used:
Operating System and version:

This problem has nothing do to with Franz!
You have to reconnect your Whatsapp webclient to your Whatsapp app running on your phone.

Got it.  Many thanks :)
On Thu, Nov 16, 2017 at 10:52 AM, Stefan Malzner<EMAIL_ADDRESS>wrote:

Closed #287 https://github.com/meetfranz/franz/issues/287.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/meetfranz/franz/issues/287#event-1345758193, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgJRRRF14TXHRTaCkGqgs1UWvLwjx2QEks5s3IR4gaJpZM4Qfzf0
.


Enhancement

Fail on missing scripts. Can we please have a check box in sql options or some other group that allows the task to fail if the folder is missing files.
@pwshliquori

Will be adding this feature tomorrow.

Feature has been added. Moved "Fail on ora- error" and "Fail on missing sql files" to new group: Advanced.
Commit: 96e321e81ce46ecd3c51ffb463b00af334c527a1


Python 3.4?

Just wondering, do you plan to support Python 3.4 (as the typing module was introduced in Python 3.5)?

To be honest: never thought about that. Just used the typing module for documentation purposes. What would be a good alternative to clarify different return types?


DROOLS-761 Guided decision trees - new test for testing of unmarshalling drls containing different line endings

See JIRA: https://issues.jboss.org/browse/DROOLS-761
Contains new test and some code generalization.

Closing because of conflicts. I will create a new one that can be merged correctly.


UT: Add diskclaim assign test cases

What this PR does / why we need it:
Add diskclaim assign test cases
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Codecov Report

Merging #379 (e47971c) into main (cfa6025) will increase coverage by 4.35%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #379      +/-   ##
==========================================
+ Coverage   20.46%   24.81%   +4.35%
==========================================
  Files          17       19       +2
  Lines         821      963     +142
==========================================
+ Hits          168      239      +71
- Misses        628      694      +66
- Partials       25       30       +5

Impacted Files
Coverage Δ

pkg/local-storage/utils/sysfs.go
0.00% <0.00%> (-44.45%)
:arrow_down:

pkg/local-disk-manager/filter/filter_disk.go
79.66% <0.00%> (ø)

...k-manager/handler/localdiskclaim/localdiskclaim.go
38.55% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Topic/threads

:rocket:

[Current coverage][cc-pull] is 95.63%

Merging [#2][cc-pull] into [master][cc-base-branch] will increase coverage by +<.01%

@@             master         #2   diff @@
==========================================
  Files            33         33
  Lines           949        962    +13
  Methods           0          0
  Messages          0          0
  Branches        129        130     +1
==========================================
+ Hits            907        920    +13
  Misses           22         22
  Partials         20         20

Powered by Codecov. Last updated by [7ba121f...6384785][cc-compare]
[cc-base-branch]: https://codecov.io/gh/aj-michael/minijavac/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/aj-michael/minijavac/compare/7ba121f663085f3e8fe4e1bfbd5eebc6e36a9b52...6384785c83901f93d0d1b134116edab5f2b77bcb
[cc-pull]: https://codecov.io/gh/aj-michael/minijavac/pull/2?src=pr

Why did you delete some of the test cases?

Allowing void methods broke those, so I deleted them (they were parser test cases, expecting a specific error message). We could probably just "fix" the outputs, but it was easier to delete them.


[ng-app-state] Use directive composition for InputValueAccessor

This should be more maintainable

This can't be done yet, since "Directives used in hostDirectives must be standalone: true." It will have to wait until either Angular's built-in value accessor directives are standalone, or that requirement is removed.


Filter by country or continent

This is quite old. Can we do this yet? If not, can we get a priority assigned to it?

Should be doable but I need (a) priority order on all these minor enhancements and (b) maybe suggestions for the major UI changes I'll need to make to accommodate all the new filter options.


[nextcloud] Redis::connect(): connect() failed: No such file or directory at /nextcloud/lib/private/RedisFactory.php#61

After pulling the latest image, I get Redis::connect(): connect() failed: No such file or directory at /nextcloud/lib/private/RedisFactory.php#61. I am also unable to download any files from Nextcloud.
The system is running Debian Wheezy (kernel 3.16)

Containers: 8
Running: 7
Paused: 0
Stopped: 1
Images: 281
Server Version: 1.12.6
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 323
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.766 GiB
Name: harambee
ID: NVCP:5M7Q:UN4F:FQCA:W4WY:NXCW:QSPC:SFNK:Y2HJ:LLCV:QRWV:F6CE
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
<IP_ADDRESS>/8

I have the same issue with the latest image. When I try to download files I get an Internal Server Error. The nextcloud log is full of Redis connect() errors.

I'm sorry for the lack of communication but there was a lot of issues about it...
My answer to your problem here : https://github.com/Wonderfall/dockerfiles/issues/128#issuecomment-281509540


Consider moving resource tables functionality to backend

This can help to dramatically increase performance for IPTs with lots of resources since IPT loads all the resources every time. It'd be better to load only requested number of resources (10, 20 etc.) instead.
For example it takes ~13 seconds to display home page for https://ipt-inpn.gbif.fr/ which has 11K+ resources

That would mean the search and sort functions would also need to be moved to the backend.


crash after zigbee steering while using BLE NIMBLE common/zb_error_indication.c (TZ-773)

Answers checklist.

[X] I have read the documentation ESP Zigbee SDK Programming Guide and tried the debugging tips, the issue is not addressed there.
[X] I have updated ESP Zigbee libs (esp-zboss-lib and esp-zigbee-lib) to the latest version, with corresponding IDF version, and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
5.1.3
esp-zigbee-lib version.
1.2.3
esp-zboss-lib version.
1.2.3
Espressif SoC revision.
ESP32-H2 & ESP32-C6
What is the expected behavior?
The expected behavior is that it does not restart
What is the actual behavior?
I have the following ecosystem
a cell phone that connects via ble to a zigbee gateway
a gateway that is put into address mode using the cell phone command
a zigbee end device that enters the network when the gateway is in address mode
What is happening is that after the cell phone connects via ble and puts the gateway in Steering mode, and the end device enters the network, and as soon as the device manages to get the said device (the end device) into the network device) restarts with the following log:
I (976) phy_init: phy_version 250,e14681b,Jan 24 2024,17:43:11
I (1016) phy: libbtbb version: 939f79c, Jan 24 2024, 17:43:26
I (1023) taskZigbee:  Zigbee Task Created
W (1024) taskZigbee: ZDO signal: 23, status: -1
I (1025) taskZigbee: Zigbee signal: SKIP_STARTUP
I (1161) gpio: GPIO[11]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (1263) taskPerifericos: perifericos Handler Task Initialized
I (2323) BLE_INIT: Using main XTAL as clock source
I (2329) BLE_INIT: ble controller commit:[217f1bf]
I (2330) NimBLE_SPP_BLE_PRPH: BLE Host Task Started
I (2530) taskZigbee: Zigbee signal: DEVICE_FIRST_START
I (2530) taskZigbee: Zigbee stack initialized
I (2672) taskZigbee: Zigbee signal: STEERING
I (2672) taskZigbee: Network steering was not successful (status: -1)
I (7816) taskZigbee: Zigbee signal: STEERING
I (7816) taskZigbee: Network steering was not successful (status: -1)
I (12960) taskZigbee: Zigbee signal: STEERING
I (12960) taskZigbee: Network steering was not successful (status: -1)
I (18104) taskZigbee: Zigbee signal: STEERING
I (18104) taskZigbee: Network steering was not successful (status: -1)
I (23248) taskZigbee: Zigbee signal: STEERING
I (23248) taskZigbee: Network steering was not successful (status: -1)
I (28392) taskZigbee: Zigbee signal: STEERING
I (28392) taskZigbee: Network steering was not successful (status: -1)
I (33536) taskZigbee: Zigbee signal: STEERING
I (33536) taskZigbee: Network steering was not successful (status: -1)
Zigbee stack assertion failed common/zb_error_indication.c:81

abort() was called at PC 0x4205272d on core 0
0x4205272d: zb_assert at ??:?

MHARTID : 0x00000000

Stack memory:
40823e20: 0x0000001b 0x00000000 0x40823e3c 0x40811004 0x00000040 0x40823fd8 0x00000001 0x40810030
0x40811004: __assert_func at /home/aebrecht/esp/v5.1.3/esp-idf/components/newlib/assert.c:34
0x40810030: spimem_flash_ll_auto_wait_idle_init at /home/aebrecht/esp/v5.1.3/esp-idf/components/hal/esp32c6/include/hal/spimem_flash_ll.h:221
(inlined by) spi_flash_hal_setup_auto_suspend_mode at /home/aebrecht/esp/v5.1.3/esp-idf/components/hal/spi_flash_hal_iram.c:143

40823e40: 0x35303234 0x64323732 0x420fb200 0x40813b78 0x40823e40 0x40813b94 0x40823e3c 0x726f6261
40823e60: 0x20292874 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x32353032 0x20643237
40823e80: 0x63206e6f 0x2065726f 0x00000030 0x00000000 0x0000002f 0x40818648 0x420fb241 0x42052730
0x42052730: zb_aps_multi_pre_link_key_init at zb_init_common.c.obj:?

40823ea0: 0x00000040 0x40823fd8 0x0000003f 0x00000051 0x00000040 0x40823fd8 0x000000fe 0x42090300
0x42090300: zb_error_raise at ??:?

40823ec0: 0x00000000 0x40818648 0x40823f20 0x42053d82 0x6e61696c 0x39306563 0x000001c0 0x0000000e
0x42053d82: zb_nvram_write_end at ??:?

40823ee0: 0x00000004 0x00000000 0x00000000 0x00000000 0x00000040 0x40823fd8 0x40823fb0 0x00000000
40823f00: 0x0000000e 0x00000030 0x40818648 0x4205608c 0x00000000 0x00000000 0x40829720 0x00000000
0x4205608c: zb_nvram_write_dataset at ??:?

40823f20: 0x00000015 0x000e0060 0x00000000 0x00000000 0x40823f60 0x40816648 0x408284be 0x42056194
0x42056194: zb_aps_keypair_write at ??:?

40823f40: 0x00000001 0x40823f60 0x00000000 0x00000035 0x00000001 0x00000000 0x00000000 0x4206c516
0x4206c516: zb_secur_update_key_pair at ??:?

40823f60: 0xfe4eeb84 0x404ccaff 0x4267695a 0x6c416565 0x6e61696c 0x39306563 0x00000001 0x00000000
40823f80: 0x00000001 0x420f8a9c 0x0000003f 0x00000000 0x00000000 0x00000000 0x420f9000 0x00000000
40823fa0: 0x4082401e 0x0000001b 0x40823fd8 0x4206cb4c 0x4267695a 0x6c416565 0x6e61696c 0x39306563
0x4206cb4c: zb_secur_create_best_suitable_link_key_pair_set at ??:?

40823fc0: 0x4082401e 0x0000001b 0x40825249 0x420690b0 0x0000001b 0x40825231 0xfe4eeb84 0x404ccaff
0x420690b0: zb_aps_unsecure_frame at ??:?

40823fe0: 0x00000000 0x0000001b 0x4eeb841f 0x00000000 0x00000000 0x4204e6de 0x00000000 0x4082952f
0x4204e6de: zb_nlde_data_indication at ??:?

40824000: 0x00000000 0x0000001b 0x00000021 0x4204e000 0x00000000 0x00000000 0x02ffffff 0xffff0000
0x4204e000: zb_nlde_data_indication_continue at ??:?

40824020: 0x30000021 0x000000fb 0x000000ff 0x00006f00 0xf4fffb30 0x00000000 0x0000001d 0x00000000
40824040: 0x0000001b 0x00000000 0x0000003f 0x00000000 0x00000000 0x4204e6de 0x7fffffff 0x000000ff
0x4204e6de: zb_nlde_data_indication at ??:?

40824060: 0x0000000f 0x00000000 0x40816648 0x4205732c 0x00000000 0x4087eed0 0x408299cc 0x00000002
0x4205732c: zb_sched_loop_iteration at ??:?

40824080: 0x00000011 0x00000000 0x40829664 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408240a0: 0x00000011 0x4082bb2c 0x408299cc 0x4082ba28 0x00000011 0x0000fdee 0x00000001 0x42048996
0x42048996: esp_zb_main_loop_iteration at ??:?

408240c0: 0x00000011 0x0000fdee 0x00000001 0x42007d04 0xffff0001 0xffff0001 0x00000005 0x00000000
0x42007d04: MyZigbeeHandlertTask at /home/aebrecht/Documents/Zentraly/Multizona_Zigbee/firmware/firmware_G2_Multizona/src/task_zigbee/taskZigbee.c:462 (discriminator 2)

408240e0: 0x00000000 0x00000000 0x00000000 0xf2010410 0x000000ff 0xffff0001 0xffff0001 0x00000005
40824100: 0x00000001 0x00000000 0x0000000a 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40824120: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40824140: 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x00003340 0x00000000 0x00440010
40824160: 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40824180: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408241a0: 0x00000000 0xc6fdc823 0xc6fec863 0xe400000a 0xfffe450b 0x04404cca 0x00000000 0x00000000
408241c0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
408241e0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40824200: 0x00000000 0x00010001 0x80020900 0x000000ca 0x00000000 0xff100000 0x00a8004f 0x00000000

ELF file SHA256: a28afcedf2fc3a84

Rebooting...

and after the reboot it can enter the network without problems
Steps to reproduce.

connect the gateway via BLE with a cell phone
Start the steering
add a end device to the zigbee network
check if the esp crash

More Information.
No response

Hi, I have the same problem. Can I solve it?

@diazmanuel @agustinebrecht  Could you please confirm if this crash log is from the Zigbee gateway?
Is the Zigbee gateway using a dual-chip solution (ESP32S3+ESP32H2) or a single-chip solution (ESP32C6)?

hello @kelin6,
I'm sorry for commenting on an error in the explanation, the device that is crashing is the final device, I also clarify that all the devices mentioned work with a single chip, the coordinator uses an ESP32C6 and the final device (which is the one that crashes) a ESP32H2. The login corresponds to the final device (ESP32H2).
The steps to reproduce it are as follows:

The coordinator (ESP32C6) is put in stering mode, follow the examples in this repository
The BLE nimble is turned on on the end device (ESP32H2) (following the example of nimble_spp_server) and in parallel the zigbee module (following the examples in this repository with the exception that the device does not begin to perform steering but waits for a command please to start it)
The connection is established between the end device and the phone via BLE and the command is sent to start steering mode
Finally the device tries to pair with the coordinator and it is at that moment that the failure and reboot occurs as shown in the logs

some clarifications:

By logging in the coordinator we were able to verify that the device managed to pair correctly, that is, the restart occurs after the pairing is achieved
In other tests we replaced the end device (ESP32H2) with a repeater (ESP32C6) respecting the previous steps and it ended up giving the same results
Finally, it is not possible for us to send you a code extract to test because it is very intertwined with other parts which makes it impossible to isolate it for testing. I believe that by following the examples we mentioned before you will be able to reproduce it, but if you do not succeed, we will try to provide you with more information.

Hi @diazmanuel,
I failed to reproduce the issue, here is the quick example code I used:
zed: https://github.com/lpy4105/esp-zigbee-sdk/tree/test/ble_zb_light/examples/ble_zb/ble_zb_light
zc: HA_on_off_switch in this repo.
It would be helpful if you could bridge the gap between the two code bases, especially the pairing process and additional flash operations if any.

hello @lpy4105 ,
We tested the example code that you gave us and it does not actually crash like in our case, we are working to bring your example closer to our use case, at the moment we could not replicate it in your code. On the other hand, in ours it continues to happen systematically, we continue analyzing our code to see if we have any errors but everything would indicate that this is not the case.
With the Log that we gave you, could you give us a little more information about where the problem could be?

With the Log that we gave you, could you give us a little more information about where the problem could be?

@diazmanuel As the log indicates, the ZB stack wrote something to nvram, but failed to verify the data. We do find some risks when multiple tasks operating the nvram at the same time and have pushed a fix in 1.2.3, but it just relieves the situation. We are appropriated if you could help to reproduce the issue, so that we could find the root cause.

Hello @lpy4105 , sorry for the delay in the response, we were trying to reproduce this problem with the code you gave us but we couldn't, we believe it is due to the use of memory in different tasks, honestly we couldn't isolate it to be able to pass it on to you and we chose to avoid the problem , that is, avoid the condition in which this error occurs, in any case we will leave the problem open and we are at your disposal if you require us to try it again in incoming sdk updates

Hi @diazmanuel, thanks for your feedback. We have just found that the similar issue from another customer was caused by calling SDK API from different tasks without protection. Please check in your project if all the API calls are protected by esp_zb_lock_acquire and esp_zb_lock_release. Hopefully this could help you resolve this issue.

Hi @lpy4105 I appreciate the mention of these functions, I understand that this reserves the zigbee resources to be able to use them from other tasks, in our case it turned out to be like this since we manage a large amount of resources from an external task, I wanted to ask you from which version was added these features because we hadn't seen them before, and reading the documentation we noticed that it was something really important that we missed. I also take this opportunity to recommend that you add some example of multitasking to be able to adopt the recommended practices, for this update as well as for future ones in case of a change as significant as this one.

I wanted to ask you from which version was added these features

I believe it was v1.1.0 that we added this support and suggested (actually it is mandatory) the user to use the pairs of lock function to protect each SDK API call outside the zigbee main task.

I also take this opportunity to recommend that you add some example of multitasking to be able to adopt the recommended practices.

This have been demonstrated in our examples, you could see the API calls in ISR context have been wrapped with the lock. Sure, we could consider adding such example.

Perfect, thank you very much, I close the issue since with the new implementation we made the error no longer occurs (indeed we were not using these lock functions that you mention so we believe it was due to that). On the other hand, I would appreciate if you could add an example of multitasking to corroborate that we are using the resources appropriately. If this example includes low consumption in multitasking, it would also be well received since this would cover most use cases.

Hi @lpy4105,
Perfect, thank you very much, I close the issue since with the new implementation we made the error no longer occurs (indeed we were not using these lock functions that you mention so we believe it was due to that). On the other hand, I would appreciate if you could add an example of multitasking to corroborate that we are using the resources appropriately. If this example includes low consumption in multitasking, it would also be well received since this would cover most use cases.


Rewriting the Proxy

The latest versions of Palindrom are considered to be too slow, and being unusable due to this.
This can be observed in the Timeline app.  (I will write step by step instructions to recreate this behavior in the Timeline app below :) )
cc @stefanedqvist @Starcounter-Jack @alshakero

To recreate this behavior:
Required Apps:
SignIn - Develop branch
People - Develop branch
Notes - Master branch
Timeline - Master branch
The lag occurs when an event is being created, and the list on the client side is being updated.
Every time a note is created, it creates an entry in the timeline.
To display the timeline, Go to a person (for example admin admin)
To create a note, either click on the "create note" button in the timeline, or scroll to the bottom of the page on the "static note creator" and create notes from there

A note is created when the button (circled by the yellow marker) is pressed.
Click it a few times, and also click on the "load more events" button in the timeline, until all the events are being displayed. And then try to delete a note, or add another note and the lag can be observed.
The lag can be experienced at around 20-30 (visible) events, but its a lot more obvious when there are around 100 events.
Creating a note event with 139 visible events

(This screenshot is taken when the timeline were displaying 134 events)

Update:
This will be fixed in https://github.com/Palindrom/JSONPatcherProxy/pull/18
Down from 858ms to 32ms (31 FPS).
Before:

After

Update:
After running the same test, but this time with @alshakero's latest version of Palindrom:
(this time with 160 events rendered)

from 2080ms to 28!!

@Joltrix  does it mean we can close this issue?

@tomalec  We should verify it works for Heads too. However might be that they have downgraded to a lower version. I´ll check with Henrik.

I have checked manually in their app the case they shown me and got ~35% performance improvement compared to the old fast version. I've also sent an info to Peter, Fredrik and Henrik with fixed version (<IP_ADDRESS>66).
But please double check if they are satisfied with the results.

Such a relief <3

Closing as done.


Human-readable context for expectations

If there's multiple expectations in a single it , currently it appears to be impossible to figure out which expectation actually failed without cross-referencing the failure with line numbers in your code.
test('api works', () => {
    expect(api()).toEqual([]) // api without magic provides no items
    expect(api(0)).toEqual([]) // api with zero magic also provides no items
    expect(api(true)).toEqual([1,2,3]) // api with magic enabled provides all items
})

Which expectation failed? The first or the second?

It would be nice if there were some human readable context that made it immediately clear which expectation failed and what the expectation output actually means in human terms, without having to find the line number at the top of the stack trace and mapping that back to the code.

Compare the tape equivalent below. Ignore that tape doesn't bail after the first assertion failure.tape prints out a human-readable message above each expectation failure, allowing you to know exactly which test failed without going back to the test file.
Note this also pushes the human-readable noise off to the end of line in the test source, where you might write a comment anyway.
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
})

It seems the only way to attach human-readable information to errors with jest is to wrap everything in an additional it which is unnecessarily verbose IMO.
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

Ideally, one could attach some human-readable context onto the end of the expect somehow.
e.g.
Context message as additional optional parameter for assertion methods:
test('api works', () => {
    expect(api()).toEqual([], 'api without magic provides no items')
    expect(api(0)).toEqual([], 'api with zero magic provides no items')
    expect(api(true)).toEqual([1,2,3], 'api with magic enabled provides all items')
})

Or context message as a chained .because or .why or .comment or .t or something:
test('api works', () => {
    expect(api()).toEqual([]).because('api without magic provides no items')
    expect(api(0)).toEqual([]).because('api with zero magic provides no items')
    expect(api(true)).toEqual([1,2,3]).because('api with magic enabled provides all items')
})

Alternatively, it'd be even better perhaps if jest could simply read the file and print the actual source code line that expectation itself is on.

Hey! So we actually used to have this in Jasmine but found that over thousands of test files at FB, nobody used it. So for now we are printing a nice error message with approximate information and a stack trace that will lead to the expectation (just like in your screenshot). I agree we could print the line that throws but quite often the assertion is multiple lines long:
expect(a).toEqual({
  …
});

so this wouldn't actually look so good and we'd have to use a parser to parse the JS and extract the relevant info (and collapse long lines) or something similar to make it pretty.
Personally I think we are showing enough information for now but happy to reconsider. If you have ideas for something that isn't very complex but adds more context which helps resolve issues faster, let me know.

@cpojer so the pattern is to wrap each assertion in an it? or just trust in the line numbers?
Is it possible that this pattern has been adopted less because it's better or worse, but more just for consistency with the existing tests?

I agree we could print the line that throws but quite often the assertion is multiple lines long

Refactoring to a single line could encourage more semantic information in the assertion? Perhaps?
const adminUser = {
  …
}
expect(a).toEqual(adminUser);

Personally I think we are showing enough information for now but happy to reconsider

The example above shows that it's difficult to discover exactly which assertion failed unless you add verbose (IMO) wrappers around everything. This is especially true in a transpiled environment where sourcemap line numbers aren't always accurate. I believe that quickly and accurately understanding broke and where is important, as are concise tests.

If you have ideas for something that isn't very complex but adds more context which helps resolve issues faster, let me know.

I made a few suggestions above:

additional optional parameter for assertion methods
chained context message

Are you looking for something simpler, or different?

hey @timoxley! we already thought about adding something like this.
so the issue with the first option is that some matchers have optional arguments, and that makes things more complicated.
e.g. here on the second case we won't know if the argument is a proximity or an error message
expect(555).toBeCloseTo(111, 2, 'reason why');
expect(555).toBeCloseTo(111, 'reason why');

second suggestion won't work because the matcher will throw as soon as something does'n meet expectation
expect(1).toBe(2)/* will throw here */.because('reason');

we could attach the reason before the matcher executes, like this:
expect(1).because('reason').toBe(2);
// or
because('reason').expect(1).toBe(2);

but this API doesn't really look that good.
another option would be to add a second arg to expect
expect(1, 'just because').toBe(2);

but it is pretty much the same as the previous option.

The reason why I think this isn't very useful is because engineers don't want to waste time writing tests. Anything we do to make it harder for them will just lead to worse tests.
In the past, the best solution was actually to create custom matchers. We'll introduce expect.extend in the next version of Jest and it will allow you to easily create matchers like:
expect(a).toEqualMySpecificThing(…)

which should allow you to write more expressive failure messages. I've seen this used a lot in projects like Relay. See all the matchers: https://github.com/facebook/relay/blob/master/src/tools/mocks/RelayTestUtils.js#L281

Closing due to inactivity but happy to reopen if there are good ideas.

@cpojer @dmitriiabramov apologies for delay.
A second arg to expect or chaining a reason with .because would be great.  In addition to not wanting to waste time debugging tests, this is exactly why I believe a less verbose API with more failure context would be preferable.
For some concrete numbers, using the example from my comment above, compared to tape's API, to get equivalent assertions + context Jest requires the programmer write:

1.8x the lines (6 vs 11)
2x the indentation (1 vs 2)
2x the parens/curlies (24 vs 48) !

This could be improved!
// tape
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
  t.end()
})

// jest
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

Thanks for keeping the conversation going. Note, that you also don't need the describe block, further making things smaller. .because won't work unfortunately because when the matcher throws (which happens before .because is called), we won't have a way to extract the name.

Use the last arg of each matcher function then?

It would only work if we add it as a second arg of expect.
We can't add it as a the last arg for every matcher function because of ambiguity
e.g.
expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

Closing due to inactivity but happy to reopen if there are good ideas.

@cpojer it's unclear if the jasmine (and others) way of expect(value).toBe(something, 'because message') has been ruled out?
One example is testing redux-saga/redux-observable stuff where you're testing a state machine. It's very helpful to have a descriptive message about at what state did it fail. That example is contrived so the descriptions are as well, though..

@jayphelps we're not using the jasmine way any more since we rewrote all jasmine matchers

@dmitriiabramov sorry my question wasn't clear. Has the jasmine way of doing it been ruled it? Doing the same thing they allow.

@jayphelps as i said before, it won't work for all matchers because of the ambiguity.
expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

and sing jest matchers can be extended with a third party packages i don't think it's a good idea to mess with the argument list

the cleanest option is probably to have it as a second argument of expect, since it always takes exactly one argument.
expect(123, 'jest because').toEqual(123);

i'm not sure if we want to overload the API though. We almost never used it in facebook test suites, and for special cases i think it'm easier to just define a new test:
beforeEach(someSharedSetup);
test('reason or description', () => expect(1).toBe(1));

it's just a few lines more :)

Or you can even put it into another describe() call.

@dmitriiabramov The annoying cases are when you build up state, like in a state machine for sagas, epics, etc. Each test requires the previous state changes, isolating them requires a ton of duplication without any gain AFAIK.
it('stuff', () => {
  const generator = incrementAsync();

  expect(generator.next().value).toBe(
    call(delay, 1000)
  );

  expect(generator.next().value).toBe(
    put({ type: 'INCREMENT' })
  );

  expect(generator.next()).toBe(
    { done: true, value: undefined }
  );
});

Or you can even put it into another describe() call.

Can you elaborate this? Nesting describe calls AFAIK was just for dividing section titles, tests are still run concurrently right?

Test suites (files) run concurrently, test() calls don't.

i'm starting to thing that something like
test('111' () => {
  jest.debug('write something only if it fails');
  expect(1).toBe(2);
});

can be a thing

From  this discussion I think a nice and semantic one would be:
it('has all the methods', () => {
  since('cookie is a method').expect(reply.cookie).toBeDefined();
  since('download is a method').expect(reply.download).toBeDefined();
  since('end is a method').expect(reply.end).toBeDefined();
  // ...
});

The usage is similar to the because one, but it just makes more of sense semantically.

Please implement an easy way to do this.  I don't use it very often, but especially for more complicated tests, it's helpful to know exactly what is failing without having to go digging.
Please don't say "rewrite your test suites to be simpler".  The only thing engineers hate more than writing test suites is rewriting test suites.
Another proposal that I've seen somewhere, I  forget where:
expect(reply.status).toEqual(200).because('the request should succeed');

I got some simple "prototype" demo working, I would need to implement the recursion now. It is a thin wrapper using Proxies around the global variables and then over each method. However, Proxies are not supported by older browsers and cannot be polyfilled so it might not be acceptable for Jest. This is the general structure for the wrapper:
const since = (text) => {
  return new Proxy(global, {
    get: (orig, key) => {
      return (...args) => {
        try {
          const stack = orig[key](...args);
          return new Proxy(stack, {
            get: (orig, key) => {
              return (...args) => {
                try {
                  const ret = orig[key](...args);

                  // ... implement recursion here

                } catch (err) {
                  console.log('2', key, text, err);
                  throw err;
                }
              }
            }
          });
        } catch (err) {
          console.log('1', key, text, err);
          throw err;
        }
      };
    }
  });
};

There are three realistic options:

This way is acceptable so it should be added to the main Jest library.
Dig deeper into Jest and modify the core library. A lot of work, so wouldn't do anything until some member(s) say something semi-oficially on this issue/direction.
Finish it this way and publish it as a package. Undesirable since it's not easily discoverable.

You need expectation context to make test results sane when you have non-trivial tests. Real-world tests wouldn't always be that simple.
Remember custom matchers - they hide mathing complexity. But when test fails, hiding this complexity is not what you want becase you want maximum info about failure. Expectation context alows you to provide this context manually. Not ideal I guess, some kind of automatic context would be better, but it is the only way I've seen by now.
When I broke something and it fails, with Jest I have to debug it manually or add logging or whatever modifications. Which is much less convenient than just look at test run results.
In Jasmine for example, we have an ability to print some context to make more sense about failure.
In Java's most popular test framework JUnit we have exact same feature too.
Sorry if I'm mistaken, but I don't see any technological counter-arguments to this feature here.

Can we reopen? Even jest.debug() as suggested by @aaronabramov above would be helpful to me.

This:

it('has all the methods', () => {
	since('cookie is a method', () => expect(reply.cookie).toBeDefined());
});

can be supported by adding this:

// setupTestFrameworkScriptFile.js
// http://facebook.github.io/jest/docs/configuration.html#setuptestframeworkscriptfile-string
global.since = (explanation, fn) => {
	try {
		fn();
	} catch(e) {
		e.message = explanation + '\n' + e.message;
		throw e;
	}
};

Also, jasmine-custom-message looks similar to what's requested:
describe('test', function() {
  it('should be ok', function() {
    since(function() {
      return {'tiger': 'kitty'};
    }).
    expect(3).toEqual(4); // => '{"tiger":"kitty"}'
  });
});

Is there any plans to reopen this? Seems like there has been duplicates issues of this one recently. I'm also looking to display custom message when test fails.

Hmm.. This is also something I've got on my wishlist. After reading this thread, I can understand the response pertaining to Jest usage at Facebook and not wanting to impact your own workflow, but there have been some suggestions that would not interfere with existing tests, and would add the functionality that several others would like to have (myself included).
What would it take for either the 2nd arg to expect() or the since() format to be accepted as a PR? I'm willing to donate some time to help with this.

I've just read through the thread and see good arguments on both sides. I definitely want a mechanism to provide a custom error message for the same reason @timoxley originally posted. Right now I'm doing something like this:
import assert from 'assert'
import chalk from 'chalk'

test('api works', () => {
  assert.deepEqual(
    api(),
    [],
    chalk.red('api without magic provides no items')
  )
  assert.deepEqual(
    api(0),
    [],
    chalk.red('api with zero magic also provides no items')
  )
  assert.deepEqual(
    api(true),
    [1, 2, 3],
    chalk.red('api with magic enabled provides all items')
  )
})

This actually works remarkably well, but I would like to avoid having to use chalk to get the red color (prints without color otherwise) and I'd prefer this to be supported by expect.
I don't really care how it's implemented honestly. But here's an alternative to since just to throw something else out there in case others prefer it:
const expectWithMessage = expect.withMessage(
  'api with magic enabled provides all items'
)
expectWithMessage(api(true)).toEqual([1, 2, 3])

// could be rewritten like
expect
  .withMessage('api with magic enabled provides all items')(api(true))
  .toEqual([1, 2, 3])

I'm not certain I like that any better than since. I'm good with whatever, I just really would love to have this :)

Oh, and to address the comment:

The reason why I think this isn't very useful is because engineers don't want to waste time writing tests. Anything we do to make it harder for them will just lead to worse tests.

I agree that we don't want to make it harder to write tests. That's why this would be an additive change. So folks who don't want to "waste time" making their tests easier to debug, they can just skip on the helpful messages, but then they'll come into a codebase that has helpful messages like this and then they'll thank the engineer who took the time to explain the assertion a little bit :wink:

Hi @cpojer any updates on this?
Jest is working great for me except for this issue... At the moment I'm struggling to fix a failed assertion within a for loop like
expectationsArray.forEach(expectation => expect(...))
It's hard to figure out exactly which expectations fail without a custom error message (unless I'm doing it wrong..?)
Thank you

@mj-airwallex you're good to wrap expectations with a test in a for loop for example:
const expectationsArray = [[0, 'a'], [1, 'b']];

expectationsArray.forEach(([expectation, desc]) => {
  test(`test ${desc}`, () => {
    expect(expectation).toBeGreaterThanOrEqual(2);
  });
});

I also have an issue with jest because of the need to provide custom messages during expectations. Wrapping expectations under test seems to work for cases where there is no need for asynchronous calls. But since Jest cannot handle describe(#2235 ) returning a promise we can't create tests with asynchronous calls along with wrapping them with test. And we can't have multiple test nested.
Here is an example to illustrate the problem:
`
async function getArray() {
return [0,0,0,0,0,0]
}
describe('Custom messages with async', async () => {
const array = await getArray();
array.forEach((item) => {
test(test${item}, () => {
expect(item).toBe(0)
});
});
})
`
Any ideas how to handle this?

Looking at the issue in the OP, I think it's solved now. As of Jest 22 we print the context of the failing assertion.

Async describe is another issue (which won't be helped by the added codeframe)

I think I'd not use async describe and instead use beforeEach or beforeAll

@kentcdodds could you provide an example how to handle this with beforeEach or beforeAll? If you try to build all the necessary async call results in beforeEach and beforeAll it will in the end force you to create nested test which is not allowed.

Ah, I missed what you were doing with that async call. Sorry about that 😅 Yeah, you couldn't do beforeEach or beforeAll to do that.

@SimenB, printing the context helps a lot already and solves most of the issues with custom messages. Thanks for this! But it would be nice to have possibility for custom messages explicitly defined with code since it helps in a situations such as using expects within loops.

@tojuhaka try this: https://github.com/negativetwelve/jest-plugins/tree/master/packages/jest-plugin-context

Looking at the issue in the OP ("It would be nice if there were some human readable context that made it immediately clear which expectation failed"), I think it's solved now.

Yes, this does solve the original issue, so long as you have access to the original source before transpilation, which most Jest users will have. IMO it's a bit heavy-handed compared to allowing users to just print a user-supplied message with the failure, but good enough I guess.

Just started using Jest and I'm missing a feature like this. My use case:
A test is failing where I assert a property of an object to be truthy. It would help me understand the failure faster if I could log the object in case the assertion fails.

You can use toHaveProperty for that.
test('property', () => {
  expect({foo: 'bar'}).toHaveProperty('baz', 'foobar');
});

If you just want to check that it's there, drop the second argument. If you just want to assert that it has some value, you can use expect.anything().
toMatchObject  is another alternative.
You can also use assert if you want.
test('property', () => {
  const obj = {foo: 'bar'};
  assert.equal(obj.baz, 'foobar', JSON.stringify(obj));
});

Thanks for the tip. assert.equal(obj.baz, 'foobar', JSON.stringify(obj)); would do the job in my particular case.

I'm using the following code fragment to hack around this limitation of the framework (in TypeScript but just remove the type annotations for JS)
export const explain = (expectation: () => void, explanation: string) => {
    try {
        expectation();
    } catch(e) {
        console.log(explanation)
        throw e;
    }
}

Hi,
I am surprised that nobody mentioned loops yet. jest-plugin-context is nice, thanks for this works, but it is a bit heavy and the initial issue is still relevant imo.
Look at this test
describe('MyStuff', () => {
    it('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];
      expectedKeys.forEach((key) => {
        expect(wrapper.find({ id: key }).length).toEqual(1);
      });
    });
  });

I think this use case is relevant, for forms and item rendering check for example.

@akkerman Nice solution. Since describe and it are magic globals provided by jest I must admit that they can feel obscure, I was not sure writing ìt` in a loop could work.

What about chaining another modifier?
expect(foo).toEqual(bar).because('reason with %s placeholders')

Or maybe a function
expect(foo).toEqual(bar).explainedBy((result) => `Lorem ipsum ${result}`)

I think another modifier quickly becomes unreadable.
T
2018-04-19 13:47 GMT+02:00 λ • Geovani de Souza<EMAIL_ADDRESS>
What about chaining another modifier?
expect(foo).toEqual(bar).because('reason with %s placeholders')
Or maybe a function
expect(foo).toEqual(bar).explainedBy((result) => Lorem ipsum ${result})
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/issues/1965#issuecomment-382705387, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAM5PwBCvET1KdEDeDEF7gGo708Naj8oks5tqHlSgaJpZM4Kc6Uu
.

--

Tarjei Huse
Mobil: 920 63 413

The way expect work is by throwing, so that wouldn't work anyways.
I think either expect(something, 'some helpful text on failure').toEqual(somethingElse) or expect.context(something, 'some helpful text on).toEqual(somethingElse) are the best alternatives, but I don't really like either of them

Can this be reopened? It seems Jest still has no good solution for testing how state changes over multiple interactions, for example:

testing how a stateful React container changes in response to a series of events
testing how a web page changes throughout multiple interactions using Puppeteer

Both of these cases require performing a series of actions, and asserting how the state changed (or didn't change) after each action, so multi-assertion tests are sometimes necessary. It's not always possible to solve this kind of problem with beforeEach.

I keep finding situations where this would be really useful. Specifically when I'm running multiple interactions and assertions as @callumlocke explains.
If we come up with an API that folks don't hate, is this something you'd be willing to pursue? I really think this would be a valuable and much used feature.

Here's a summary of the possible proposed solutions in this thread to solve context in expectations:
expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

expect(api(), 'api without magic provides no items').toEqual([])
expect(api()).because('api without magic provides no items').toEqual([])
since('api without magic provides no items').expect(api()).toEqual([]))
because('api without magic provides no items').expect(api()).toEqual([]))
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

Note that a trailing .because() is not possible, so not included as an option
All four options in the first group are supported today. Personally, I find that the first option (a code frame with a comment) works great. And even better than that is using a custom matcher (option 4).
I think what's we need to understand to make movement on this is: what's more appealing about the options in the second group than the options in the first? What does the second group add missing from the first which can justify core maintenance for all of the matchers we provide (across async matchers, asymmetric matchers, spy matchers, throw matchers, promise matchers, and custom matchers)?

Hi,
You basically got 2 use cases:

Multiple assertions tests (you need to test multiple things)
Dynamically generated assertion context (you want a variable in your failure message to make it clearer, e.g for printing a specific field of your failing object because you got a lot of tests)
Dynamically generated assertions (you make a loop that generate assertions)

First group options are mainly meant for the first use case. If you encounter the need for dynamically generated assertion, as proposed, you can nest calls to it and test, so that a test can generate new tests in a loop. The problem is that you generate tests and not assertions. Imagine that I want to assert something on each element of a 1000 elements array, this will bloat the test summaries.
Since those dynamic use cases are still rare though, imo we should stick for the solution that requires minimal work for the maintainers. I personally like the because/since solution, because it sounds quite simple. I guess the implementation would be mostly wrapping  expect in a try/catch that prints the message and returning it?
jest.debug sounds weird, to me debugging is printing a message even if the tests actually passes
The "last argument" option is also good but I am not sure if it is doable since expect can accept a variable number of arguments?

I'm fine with any option. I just want the feature. I'm not huge on the jest.debug API either, but if it's the only one that makes sense I'm fine with it because I just want this feature.

@kentcdodds what about the four existing options?
@eric-burel have you seen test.each and describe.each added in Jest 23 (available as a standalone for Jest <23)?

Like I said, I don't really care which option we go with. I just want the feature to exist. I guess if I were to sort them by order of preference it would be:

expect(api(), 'api without magic provides no items').toEqual([])
because('api without magic provides no items').expect(api()).toEqual([]))
since('api without magic provides no items').expect(api()).toEqual([]))
expect(api()).because('api without magic provides no items').toEqual([])
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

(test|describe).each is great, but doesn't solve the issue where you want to have multiple actions/assertions in a single test.

The feature does exist today with four options:
expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

What is wrong with these? The proposed new solutions only seem to be marginally better than these existing solutions. What benefits do they bring over what we have that justify the maintenance cost?

@rickhanlonii Nice I did not know about test.each, that's truly a great feature, thanks for pointing this out. I think it solves the issue for my 3rd use case, dynamically generated test from an array.
So it left the second I listed: having a dynamically generate failure message, which would make debugging faster. I don't have much use cases right now, maybe when you test an object field value, you would like to print the whole object on failure. That's legitimate imo, as anything that makes writing test easier, even if marginal or a bit redundant. After all we can both write it and test, unless there is a difference I don't know about this is mostly for comfort.
It is marginal but really something expected (no pun) by users, as this thread shows.

This is crazy. Just add a second, optional parameter to expect(). Those of us who want to use it will (selectively), and those who don't, won't.
Mocha has been doing this forever... it's one of the reasons I abandoned Jasmine years ago (the other being much better timer mocking.) If I weren't having to join the React bandwagon, I wouldn't be using Jasmine or any other derivative.

@mattphillips do you think it's possible to do something similar to jest-chain here to allow a solution to exist in userland? E.g. second argument to expect

Honestly, this is something very standard in most JS testing frameworks. Very disappointed not to find it in Jest as we write all of our tests with a custom error message.

@SimenB sorry I only noticed your message this morning!
Yes this is doable in userland, I've just knocked it up and released it as jest-expect-message https://github.com/mattphillips/jest-expect-message
Feedback welcome :smile:

Awesome, thanks for doing it!

@cpojer

The reason why I think this isn't very useful is because engineers don't want to waste time writing tests. Anything we do to make it harder for them will just lead to worse tests.

Two things:

Adding an optional second argument to expect() is hardly making anything harder for developers.
The last thing developers want to do is waste time debugging what caused the test to fail. Often expects vs received is a good way to check if a condition was met, but often not enough context as to what caused it to fail.

I used Mocha/Chai, as well as tape, before coming to Jest, and this is really a deal breaker. What do we have to do to get a custom message support into expect?
Telling us to expect.extend in order to create a custom matcher sounds exactly like what you were trying to avoid in your first argument: "engineers don't want to waste time writing tests."

I find it easy to open the unit test and look at the line number, so the use-case in the OP doesn't bother me.
The use case that bothers me is when I have a loop inside a test, e.g. to test every value of an enum, for example like this:
it("Should return read itself", () => {
  for (const wordType of wordTypes) {
    expect(words.find((word) => word.wordType === wordType)).toBeTruthy();
  }
});

If that fails then I don't know which wordType value failed.
My work-around was to replace that with a message which contains the test result, and expect that the message contains the expected test result (i.e. true). If it fails then Jest prints the message which contains the additional information.
    expect(`${wordType} ${!!words.find((word) => word.wordType === wordType)}`).toEqual(`${wordType} ${true}`);

Jest prints this ...
expect(received).toEqual(expected)

Difference:

- Expected
+ Received

- 6 true
+ 6 false

... which tells me that the wordType was 6 when it failed.

@cwellsx check out parameterised tests with test.each this way each wordType will be an independent test with a descriptive title (based on the value)

This would be incredibly useful in tests like this:
test("compare ArrayBufferCursors", () => {
    const orig: ArrayBufferCursor;
    const test: ArrayBufferCursor;

    expect(test.size).toBe(orig.size);

    while (orig.bytes_left) {
        expect(test.u8()).toBe(orig.u8());
    }
});

Right now I only know some byte in the ArrayBufferCursor is wrong but I have no idea which one. Being able to add an index as context would make debugging much easier. Thankfully some people have presented workarounds here but they're all ugly and slow.

@rickhanlonii, I understand that you want to reduce the maintenance costs of jest, but options that you offer in your comment increase the maintenance of unit tests of all other projects. If I want to explain an assertion using toEqual, which is otherwise perfectly enough, are you really suggesting me introducing a custom matcher?!
While there are cases with repetitive tests, where it.each are useful, having to add an unnecessary code for a simple comment on an assertion makes this test framework heavier to use.
This discussion and emerging of jest-expect-message reminds me about the beforeAll issue in Jasmine...

I may be misunderstanding the OP's request here but the problem that I was trying to solve and brought me to this issue thread was solved just using a simple try / catch. All I wanted to do was log the entirety of the objects that I expected vs the ones that I received + some basic logs explaining the significance.
The most generic version of this might look like:
`
in some test utility file...
const myExpect = (expectFn, errorCallback) => {
try {
expectFn();
} catch (err) {
errorCallback();
throw new Error(err);
}
};
// in the actual test suite...
const context = { hello: "world", results, expected };
myExpect(
() => expect(results).toEqual(expected),
() => console.error("[Error] -- context:", JSON.stringify(context))
);
`

+1
Hi, I'd really love this feature as well. It would make my life so much easier.

I found this closed issue while trying to find out what was the syntax for exactly this in jest. I'm surprised that it's not present, already.
I would also like to see this added.

Closing due to inactivity but happy to reopen if there are good ideas.

@cpojer can we reopen this? There have been some good ideas.


payload is not being retrieved at the Server.

It's not being shown in req.body.payload.

First things first: payload is the name of the argument to sse.js to tell it what payload to send with your request. That payload will directly become the request's body, so you should be looking for req.body, not req.body.payload, on the server side.
That being said, that still won't be enough to make it work talking to an Express app. By default sse.js will not set a content type on the POST request when sending your payload. This means it will simply be sent with Content-Type: text/plain. Neither the JSON or URLEncoded middlewares of Express will get you the request body in that situation.
As explained in the example at https://expressjs.com/en/api.html#req.body:
app.use(express.json()) // for parsing application/json
app.use(express.urlencoded({ extended: true })) // for parsing application/x-www-form-urlencoded

I recommend you make sse.js set a header that's appropriate for your request, for example to send a JSON payload:
new SSE(url, {
  payload: '"Hello!"', // A simple JSON string
  headers: {'Content-Type': 'application/json'}
});

And on the server side, just use the JSON middleware:
app.use(express.json());

Now your req.body will contain the string Hello!.

Tried to send payload with Content-Type:application/json but getting an error on node server
"SyntaxError: Unexpected token " in JSON at position 0". See attached images

Oh I guess just "Hello!" isn't valid JSON. Just pass in a valid JSON string as payload.


Youtube stream help

I'm just starting learning on my own; I would like some guidance on how to make the bot play youtube streams. When i queue one, it stops after a second and tells me it stopped cause playlist not repeatable, I enabled that, and it still won't work. It's probably not the case but I did it anyways.

You can't atm.


Removes duplicated block of code - creds angular

There was a block of code duplicated rendering partial
for "Validate" button in auth credentials angular partial
once with condition set to return value of showVerify call
and the other was the same call with the same args but negated.
This patch removes that duplication.

Asked about this @AparnaKarve on gitter.

@dclarizio @h-kataria please review

Will have @AparnaKarve review this . . . it is not a high priority and is not needed in Darga.

LGTM
@petrblaho Can you open/close this PR so that Travis passes?

We do not need this anymore as these changes were incorporated in #8540 and so are merged here https://github.com/ManageIQ/manageiq/commit/8b42990081189af5fd202019d4c5bf29f4148bd8
I am closing this PR.


[Florianópolis-SC] ArcTouch - iOS Developer

Empresa
ArcTouch helps brands to connect more deeply with customers through custom experiences for phones, tablets and smart things. We transform app ideas into experiences for a wide range of connected devices you hold in your hand, wear on your wrist, and use in your home and car. Our world-class clients range from Fortune 500 businesses to well-known brands and influential startups, including NBC, Honeywell, Yahoo, CBS, Guess, Salesforce, Skyjet, Audi, and many more. ArcTouch is part of Grey, a WPP company.
Descrição da vaga
ArcTouch is hiring skilled, creative, and adaptable iOS Developers/Engineers to create awesome products for big international companies.
Posição
Middle or Senior
Tipo de contratação
Presencial - Florianópolis -SC
CLT
Requisitos

Objective-C and/or Swift
Experience with Agile, Test Driven or Behavior Driven Development
Solid understanding of iOS SDK on frameworks such as: UIKit, CoreFoundation, GCD, Auto Layout, Storyboards etc.
Advanced object-oriented programming and knowledge of design patterns
Familiarity integrating apps to RESTful APIs
BS degree in Computer Science or equivalent
English - Fluent

Benefícios
Flextime, Cross Cultural Daily Experience, Tech Talks, No dress code, 1 weekly lunch (for free <3), Subsidy Academy, English Classes, Happy Hours.
Como aplicar
Send us your resumé or (Linkedin + contacts) for<EMAIL_ADDRESS>Contato
<EMAIL_ADDRESS>https://arctouch.com/

@NatCarneiro Já existe uma vaga aberta para ArcTouch - https://github.com/CocoaHeadsBrasil/vagas/issues/67 - Podemos fechá-la?


Move the kernel API intrinsic functions to a sycl submodule

The intrinsic functions in the kernel API are presently called using the numba_dpex module qualifier. It may be cleaner conceptually if these functions are moved to a sycl submodule. Doing so will help people to easily port SYCL kernels to dpex kernels.
E.g.,
from numba_dpex import sycl

@sycl.kernel
def vecadd(a,b,c):
   i = sycl.get_global_id(0)
   a[i] = b[i] + c[i]

Having the module qualifier is much better in terms of overall readability and letting users know that the code is specific to the numba_dpex kernel API and will not work outside of the kernel function or without the kernel decorator.
Originally posted by @diptorupd in https://github.com/IntelPython/numba-dpex/issues/694#issuecomment-1276531302

The submodule name should be workitem, rather than sycl, since the corresponding SYCL most aligns with
sycl::nd_item::get_global_id, especially considering that the same namespace is going to expose barrier and group.
Originally posted by @oleksandr-pavlyk  in https://github.com/IntelPython/numba-dpex/pull/694#issuecomment-1276540895

Ongoing work in experimental addresses the issue.


Use java 8

This fixes #121.

When I run gnag locally it passes without flagging this issue, not sure where the inconsistency is coming from.


Screen flickering

Describe the bug
In the cycle text component page screen is flickering when the text is changing
To Reproduce
Steps to reproduce the behavior:

Go to 'https://animata.design/docs/text/cycle-text'
See error

Expected behavior
The screen should not flicker while the text change
Screenshots

@ankitpanwar070798 Could you share a video?

https://github.com/user-attachments/assets/0336db68-63af-4710-92b6-5b0b0f06da9e

Hey Codse/Animata
Yeah why not but I have fix the code in local will push the code and raise
MR SOON
On Tue, 23 Jul 2024, 11:11 am Akash Patel, @.***> wrote:

https://github.com/user-attachments/assets/0336db68-63af-4710-92b6-5b0b0f06da9e
—
Reply to this email directly, view it on GitHub
https://github.com/codse/animata/issues/153#issuecomment-2244296442, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ASDIIJQSBU4D3N6C6YGVK43ZNXUIBAVCNFSM6AAAAABKYN2IJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBUGI4TMNBUGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Closed by #156

Awesome, thanks for the update! I would love to help you guys if needed
just let me know
On Tue, Jul 23, 2024 at 1:47 PM Hari Lamichhane @.***>
wrote:

Closed #153 https://github.com/codse/animata/issues/153 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/codse/animata/issues/153#event-13611813602, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ASDIIJQXFXIYZUQVMQMKYBDZNYGRFAVCNFSM6AAAAABKYN2IJWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGYYTCOBRGM3DAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


chore(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vpc to v2

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vpc
module
major
v1.0.2 -> v2.0.0

Release Notes

terraform-ibm-modules/terraform-ibm-landing-zone-vpc
v2.0.0
Compare Source
Features

additional functionality added along with fix of double ACL for rule names (#33) (21166c1)

BREAKING CHANGES

vpc_name variable is now called name

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

GitHub release
v1.0.1

Your semantic-release bot :package::rocket:


[MM-45271]: custom group admin console page

Summary

adds a new row to the system roles section of the system console.
adds the details page with a dummy text (tbd by @cwarnermm?)

Ticket Link
MM-45271
Related Pull Requests

Has server changes: https://github.com/mattermost/mattermost-server/pull/20573

Screenshots
Overview page

Detail page

Release Note
NONE

@laneycs please assign UX since I do not know who is responsible for this.
Also cc @furqanmlk for future QA review (will add the QA label and review request once this is good for review)

@laneycs please assign UX since I do not know who is responsible for this.
Also cc @furqanmlk for future QA review (will add the QA label and review request once this is good for review)

I believe @matthewbirtch would do the UX review, correct me if I'm wrong though Matt.

Looks great - can you please make sure the role is called "Custom Group Manager" as opposed to "Custom Group Admin"? This is more consistent with existing language. Thanks!

Thanks for the quick change re: role title. Synced up with @cwarnermm and we're thinking for the dummy text that's still not filled that instead of each permission description being broken up we have:
"This role has permission to create, edit, and delete custom user groups by selecting User groups from the Products menu."

E2E tests not automatically triggered, because the PR is not in a mergeable state. Please update the branch with the base branch and resolve outstanding conflicts.

@michelengelen Is this still Work In Progress? I didn't want to send this to @furqanmlk if it was.

/e2e-test

@michelengelen
I noticed that server PR has been merged. But a user who is neither System Admin and nor Custom Group Manager can still create, edit, delete custom groups.
Please advise

@michelengelen I noticed that server PR has been merged. But a user who is neither System Admin and nor Custom Group Manager can still create, edit, delete custom groups. Please advise

@furqanmlk this is because the permission to do so is still enabled for all System Users in the System Console. See below for instructions to test (I've verified this works as well):

System Admin goes to System Console > System Roles > Custom Group Manager and adds anyone who should have permission to modify custom user groups to the new Custom Group Manager role.
System Admin goes to System Console > Permissions > Edit Scheme and under the All Members section unchecks the Custom Groups permission.
Then if you login as the test user-1 you'll see that a user that is not a  System Admin and nor Custom Group Manager will not be able to manage groups


Fix tab behavior for accessibility

Tab selection was not possible when tabbing
through an element that was outsideo of the
current view.
This changes the behavior, so that you can
tab through all the slides if they have an
element that can be focused (e.g.  link).
When you tab to a slide outside of the current
view, slick will automatically switch its
position so that the slide comes into view.
I'll try to make a jsfiddle that reproduces the issue.

Not a good idea I think because it Will force user to go trougth each tabs instead of letting him choose one. Imagine you force mouse user to click on every slide before to be able to read the rest of the page

No forcing. With screen readers, you can easily jump/skip, e.g. from one <h1> to the next <h2> to the next <h2> etc, and also jump between sections of the site like <nav> or <article>. Tabbing through every single element is only something you do if you really want to.

Not if you are simply using keyboard navigation and not a screenreader user

I would think "power users" of keyboard navigation usually have their keyboard shortcuts setup as they need them.
More importantly, the only thing that's more annoying than having to tab through elements, is not being able to interact with an element at all (without a mouse). E.g. in a carousel like "featured articles" (like the frontpage of a newspaper or magazine), you would need to be able to select every element, in order to navigate to the full article.

I'm not aware of any shortcut for keyboard only user to skip a block of content. Futhermore i don't say that slide must not be focusable but only that it must be the same as for mouse user. If you want to go next prev use the next prev button. If you want to go to specific slide use dots navigation. Then the focus must be moved on the current slide but only on that one.

I'm not aware of any shortcut for keyboard only user to skip a block of content.

This is how you do it with a screen reader: http://www.chromevox.com/keyboard_shortcuts.html
I agree that it should be "the same" as mouse over, in the sense that tab navigation is basically the same as mouse over (I think).
Carousels are fundamentally inaccessible unless you are sighted and can use a mouse to navigate; it's the combination of multiple pages, multiple slides per page, prex/next buttons and dots, they all make sense if you can see the visual layout in front of you, but not so much if you cannot. Then you get a lot of cognitive overhead, which is tiring. (As opposed to simply tabbing through the items one-by-one). Also, keyboard navigations users are already used to the habit of tabbing through lots of elements on every page; the usual helpful trick for that is for website developers to implement a "skip to main content" link.

If you want to go to specific slide use dots navigation. Then the focus must be moved on the current slide but only on that one.

Yes, it's possible, but very annoying, because you don't know what's "hidden behind" each dot until you navigate into it, so you'll have to jump back and forth between slides and dots to iterate through the elements.
Which user group do you have in mind exactly? Sighted users that choose to navigate with the keyboard?

I know how to do it with screenreader I mean for keyboard only user.

Then you get a lot of cognitive overhead, which is tiring. (As opposed to simply tabbing through the items one-by-one)

tabbing true lot of slides can be tiring and cognitive overload too

because you don't know what's "hidden behind" each dot until you navigate into it

that's why you need to have explicit label for dots and prev / next button especially if you use infinite carousel (there another pull request for that)

Which user group do you have in mind exactly? Sighted users that choose to navigate with the keyboard?

yes or low vision user or anyone, as I already say for me no reason to impose reading or going trough the whole carousel when mouse user don't have to.
Another reason to do it that way is that there is others issue/pull request about using aria tabs design pattern for slick. If you look at aria design pattern for tabs user don't go trough the whole tabpanel simply by using tab key


Make ortools dependency optional

We want the library to work without ortools as long as we do not use the functions using it.

Perhaps we want to have a warning when the module decomon/numpy/milp/activation.py is imported without ortools being installed ? Or just have an explanation in docs about when and why ortools is needed ?

We could use a tag and when specific functions are use (boud_A, bound_B with solver=ORTOOLS) raise an ImportError ?

Ok for the error.
I do not understand what you mean by a tag. Do you mean to be able to install ortools with
pip install decomon[supertagname] ?

Ideally we would like also a test with these functions.
Then we could check

in an environment without ortools, that the error is raised
in an environment with ortools, that the functions work as expected


enable push nuget package to myget, using jayjaywg trial account

Current coverage is 76.22%

Merging #316 into master will not affect coverage as of 039ffc4

@@            master    #316   diff @@
======================================
  Files           41      41
  Stmts         4076    4076
  Branches       353     353
  Methods
======================================
  Hit           3107    3107
  Partial        148     148
  Missed         821     821

Review entire Coverage Diff as of 039ffc4

Powered by Codecov. Updated on successful CI builds.


ExpandAll/ContractAll

Hello
is there some examples for Expand All and Contract All nodes, please?
Thank you.

Please?

HTML
<button class="expand-all">Expand all</button>
<button class="collapse-all">Collapse all</button>

JS
$('.expand-all').click(function() {
	$('.tree tr').treegrid('expand');
});
$('.collapse-all').click(function() {
	$('.tree tr').treegrid('collapse');
});

That's it, you are the man, thank you.

This works only if you have fully loaded tree (not lazy-load)

It works perfect, I load full tree, thank you again.


[FEATURE] Create AutoSubmit to Conda-forge github action

Is your feature request related to a problem? Please describe.
Many python packages at pypi is contributed by github actions automation. If contribution to pypi and conda-forge(via grayskull) can be done sequentially, it'd make package maintenance easier.
Describe the solution you'd like
Github action which will pull data from currently specified pypi package, run grayskull, and submit it to conda-forge
Describe alternatives you've considered
Manual run, submit each release

A new package. I think the automated new release submit process already works beautifully, and is far more important, though.


SHADOWED_VARIABLE warning is unclear for derived classes

Godot version
v4.0.stable.official [92bee43ad]
System information
Steam OS Holo, Steam Deck
Issue description
The SHADOWED_VARIABLE warning is unclear when the shadowed variable belongs to a user-defined base class.
Base.gd
extends Node

var inherited

func foo(name : String):
	pass

Derived.gd
extends "res://Base.gd"

var shadowed

func bar(inherited):
	pass

func baz(shadowed):
	pass

The use of name in Base triggers a very clear SHADOWED_VARIABLE_BASE_CLASS warning:
W 0:00:00:0492   The local function parameter "name" is shadowing an already-declared property at the base class "Node".
  <GDScript Error>SHADOWED_VARIABLE_BASE_CLASS
  <GDScript Source>Base.gd:5

However, the use of inherited in Derived triggers a SHADOWED_VARIABLE warning that does not reference the base class:
W 0:00:00:0493   The local function parameter "inherited" is shadowing an already-declared variable at line 3.
  <GDScript Error>SHADOWED_VARIABLE
  <GDScript Source>Derived.gd:5

To demonstrate how confusing this could be, I've deliberately set things up here such that shadowed triggers a warning pointing to the same line number, despite shadowing a different variable defined in a different class:
W 0:00:00:0493   The local function parameter "shadowed" is shadowing an already-declared variable at line 3.
  <GDScript Error>SHADOWED_VARIABLE
  <GDScript Source>Derived.gd:8

Steps to reproduce
Run the minimal reproduction project.
Minimal reproduction project
ShadowedVariables.zip

stumbled over this, thanks to this issue I am no longer questioning my sanity

looks like the same issue also for function parameters
extends Node

var _report :String

func foo(report: String) -> void:
	_report = report

func report() -> String:
	return _report

(SHADOWED_VARIABLE):The local function parameter "report" is shadowing an already-declared function at line 11.
The function argument report on foo()  is an argument and do not shadow the function report()

extends Node

var _report :String

func foo(report: String) -> void:
	_report = report

func report() -> String:
	return _report

(SHADOWED_VARIABLE):The local function parameter "report" is shadowing an already-declared function at line 11. The function argument report on foo() is an argument and do not shadow the function report()

It does shadow it, within foo:

self.report refers to the report: Callable member function.
report refers to the report: String local function parameter. This is shadowing.

However, it's kind of partial shadowing because it seems like report() is treated/recognized specifically as a method call and thus when resolving what report means in there only the methods are considered, the local variables/arguments are not taken into account (just a suspiction, haven't actually looked into the code). Hence no name collision found / no shadowing detected.

self.report() refers to the report: Callable member function.
report() refers to the report: Callable member function. Kinda inconsistent/confusing!

Being strict/consistent shouldn't report() fail in such case? :thinking: Not sure if that's desired/feasible though. Up to the GDScript team. :upside_down_face:

looks like the same issue also for function parameters

I'd say the above is a separate issue.

It does shadow it, within foo:

It should not be recognized as a shadow, it is a local typed parameter of type string.
On the heap within the function foo there is a variable named report of type string, the parser should be able to distinguish between a local variable or a function reference (callable).

Can you explain why you just downvote without any comments?
As I said, the function argument report cannot be a shadow of the function report()!
It is just a string type variable used as a function parameter, it cannot be a callable.
This is simply a problem of the parser implementation, and you are not ready to fix it.
The parser should be able to distinguish between a local variable and a script function.

In 4.x, variables and functions share a common scope. When you call a function without parentheses, you get it as a Callable. Accordingly, the local variable (parameter) report in the foo() function shadows the report() method, you can no longer get it as a Callable using the report identifier. Yes, you can still use self.report, but it doesn't matter, we're talking about report.

Thanks for the explanation 👍

In 4.x, variables and functions share a common scope.

You say it shares, so it will hold both a variable and a function with the same name?
I guess I understand the main issue here, a function can be used as a Callable by using the plain name.
e.g. <signal>.connect(<Callable>) as node.connect(my_function)
From my perspective, this is a self-made issue by allow the plain function name as a Callable, sure this has potential to conflict with variable names.
So my question, what was the design decision to allow plain names as Callable reference?
Why it was not designed to use like a link symbol to reference to a Callable.
e.g. node.connect(@my_function)
I'm just thinking loud ;)

You say it shares, so it will hold both a variable and a function with the same name?

No. Let me explain in more detail.
3.x
In 3.x, variables, functions and signals live in separate scopes. We have warnings PROPERTY_USED_AS_FUNCTION, CONSTANT_USED_AS_FUNCTION, and FUNCTION_USED_AS_PROPERTY but overall it works. Functions are not first class values, you cannot get them as Callable. You can't call variables either. So there's no conflict here, although it's a little confusing.
Variables
=========
a: 0
b: 1
c: 2

Functions
=========
a: 0
f: 1
g: 2

4.x
In 4.x, functions and signals became first class values. You can get a function as a Callable and call it later. Now there are no separate tables, there is a common member table:
Members
=======
a: 0 - Function
b: 1 - Variable
c: 2 - Variable

So my question, what was the design decision to allow plain names as Callable reference?

This is a common approach. JavaScript and Python also do not have separate scopes for variables and functions. I find it more obvious to have just one scope for all identifier types, since there are already several locality scopes (global, class and block). Why have several identifiers of the same name that mean different things?

Why it was not designed to use like a link symbol to reference to a Callable.
e.g. node.connect(@my_function)

Some languages use sigils for identifiers of different types. For example in PHP you can have a function f and a variable $f. But the benefits of this option are not convincing and it is less convenient to type.

All right, thanks for diving deeper in this topic to give me a better understanding.

I have been working on a PR for this and I wonder which of the following solutions, if any, would be preferred. I have attached a screenshot for the result of each solution.

Use the SHADOWED_VARIABLE warning and add extra information to the last symbol if needed (e.g. the shadowed variable is in a parent class).

Use the SHADOWED_VARIABLE_BASE_CLASS warning.

Create a new warning SHADOWED_VARIABLE_PARENT_CLASS which contains both the line number and parent class.

I don't think we need a new warning type. The comments, the messags and the documentation all say the same thing:
https://github.com/godotengine/godot/blob/2ad452ad5b513a72cce9713938deb8be230ed950/modules/gdscript/gdscript_warning.h#L56-L57
https://github.com/godotengine/godot/blob/2ad452ad5b513a72cce9713938deb8be230ed950/modules/gdscript/gdscript_warning.cpp#L62-L67
https://github.com/godotengine/godot/blob/2ad452ad5b513a72cce9713938deb8be230ed950/doc/classes/ProjectSettings.xml#L563-L568
However, SHADOWED_VARIABLE_BASE_CLASS is never produced for GDScript classes, SHADOWED_VARIABLE is always produced:
https://github.com/godotengine/godot/blob/2ad452ad5b513a72cce9713938deb8be230ed950/modules/gdscript/gdscript_analyzer.cpp#L5841-L5873
So we should:

Fix the bug in the analyzer, shadowing inherited members should produce a SHADOWED_VARIABLE_BASE_CLASS warning, not a SHADOWED_VARIABLE one.
Add the optional at line %s part to the SHADOWED_VARIABLE_BASE_CLASS warning (missing for native classes).
We should probably add the in this class part to the SHADOWED_VARIABLE warning message for clarity.
We should also update the documentation, since in 4.x a variable can shadow not only a variable, but a class member of any kind.


proot: 20190510 -> 5.1.0

Motivation for this change
Fix repology entry. and update the package
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

$ nix path-info -Sh ./result
/nix/store/1gz638vyk1k8cmypj8zrflaj3yfg9jdy-proot-20190510        94.4M
$ nix path-info -Sh ./result
/nix/store/qzwdwjsqn9px5dfs8g5rrppqqjcnpppx-proot-5.1.0   94.1M
$ nix-review wip
...
[2 built, 14 copied (21.6 MiB), 4.4 MiB DL]
2 package were build:
proot udocker

@grahamcofborg build proot pkgsStatic.proot

This release appears to be from 2014: https://github.com/proot-me/proot/releases/tag/v5.1.0. There are numerous fixes we need to have available:
https://github.com/proot-me/proot/compare/v5.1.0...master

you are absolutely correct.. ill flag it on repology then.

Decided against flagging it on repology, there an open issue here https://github.com/proot-me/proot/issues/127 already for cutting a new release. Hopefully a new release reflects the current state of the project :(

Closing issue due to nature of package releases.


Temporary Store

Description
We need the ability to temporarily store a bitmap result for later use.
These results can be stored, retrieved and purged.
We should discuss if there should be an implicit or explicit TTL for stored bitmaps
Also what should happen we attempting to overwrite an existing stored result
Stored bitmaps are not persisted after restart, but the values should persist through Cluster resizing.
Storage
Bind(<id=STRING>, [BITMAP_CALL])

Retrieval
Load(<id=STRING>)

Or simply used the previously bound ID name as a bitmap?
Delete
Purge(<id=STRING>)

Example
Bind(id=commits, Range(frame="stats", commitactivity > 100))

Intersect(commits, Bitmap(frame="stargazer", stargazer_id=1))

Success criteria (What criteria will consider this ticket closeable?)
Can used the Stored bitmap by name in any PQL operation requiring a bitmap.
Any bitmap can be stored, retrieved, and purged.

Previous discussion: https://github.com/pilosa/pilosa/issues/637

and I think @tgruben implemented this with a plugin

I think #637 and #1240 will cover this. I don't think it's worth adding features like TTL and not persisting through restarts unless we start to feel a distinct need for them


support mask password when show create query

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Category (leave one):

Improvement

Short description (up to few sentences):
Passwords that support masking MySQL engines and maybe related #6217
Fixes #3311

@akuzm Done.

This patch introduces a lot of complexity. 34 files patched, many prototypes changes.
Perhaps it's time to come up with a clean way to store hostname/secrets/credentials instead? Either in flat file, a table or similar. The logic is already there for dictionaries and could be reused.
We had a security alert weeks ago due to MySQL passwords and hostnames being exposed in CH SQL admin/query tools recently. Adding masking code to every tool isn't possible.
Apologies for the fly-by comment if this has already been discussed.
Related: #6358

@geldot is right.
close it.


Accept-Language headers seem to be read wrong.

Hi. When I send a request to wttr.in through my browser, which sends an Accept-Language header of:
Accept-Language: en-GB,en;q=0.8,fr-FR;q=0.6,fr;q=0.4,es-ES;q=0.2,es;q=0.2,ko;q=0.2

I see the results in French.
English is the first requested language, and the quality value is set to 0.8.
Why am I seeing output in an accepted-language of lower quality?

(The geolocation resolves to where I live in the UK, too.)

fwiw, I experience the exact same thing ... although from Canada 😉
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,fr;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Host:wttr.in
Pragma:no-cache
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (iPad; CPU OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1

It's definitively a bug

The problem was fixed by @talyian in #304. Please test, if it works for you know, but it definitely should.
@half-cambodian-hacker-man Anthony, in your case en-GB (i.e. en) should be chosen, but not because it is first, rather because its weight is 1 (if q= is not specified, as in the case of en-GB, it defaults to 1).


Fix stable fetch bug when using tags

The bug was that when the bundle.json specified a tag all
invocations of stable fetch after the first one would fail due
to the git checkout being in a detached HEAD state. This commit
fixes the bug.

Thanks!


Magic Bees Cross-Mod Recipes

Adding cheaper recipes that use materials from other mods can make magic bees a bit more fun to play with and incentivize other mods and reward players for investing in that mod if they decide to start Forestry. Maybe we can give increased output if a player uses every magic mod?
List of mods we can use materials from

Astral Sorcery
Botania
Thermal Expansion (Magic bees adds bees for it) + Abyssalcraft
Thaumcraft and Blood Magic (When they come out)
Dungeon Tactics + Evilcraft + Reliquary

Feel free to suggest other mods Magic Bees items can be crafted from.

TE and Abyssalcraft has been taken out. I should probably start working on the other ones.


[KP-812] Update documentation

https://kaholo.atlassian.net/browse/KP-812

replaced with a better formed PR


Make shader editor won't pop up error toasts too often, only do it when manually save

This pr addresses part of https://github.com/godotengine/godot/issues/88616, it make the text shader editor won't apply the ongoing shader when it failed to compile, thus greatly reduce the situation where toasts pop up and block the error message.
However it might has side effects that I did not find out, feel free to correct me.

@jsjtxietian This needs to be rebased, just a reminder.


[EG] Namespaces GA

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-eventgrid