Builtin proxy backend failure

Hi,
I have followed the installation guide from the proxy documentation. I am using an Ubuntu 22.04 VM.
First I tried to use next branch as pointed out by the doc but configure file was not found. So I downloaded memcached-1.6.22 from the memcached site.
wget https://memcached.org/files/memcached-1.6.22.tar.gz
tar -xvf memcached-1.6.22.tar.gz
cd memcached-1.6.22
./configure --enable-proxy

this outputs:
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for icc in use... no
checking for clang in use... no
checking for gcc options needed to detect all undeclared functions... none needed
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking whether __SUNPRO_C is declared... no
checking for gcc option to accept ISO C99... none needed
checking for sasl/sasl.h... no
checking for gcov... /usr/bin/gcov
checking for main in -lgcov... yes
checking size of void *... 8
checking for library containing clock_gettime... none required
checking for library containing socket... none required
checking for library containing gethostbyname... none required
checking for libevent directory... (system)
checking for pkg-config... no
checking for library containing gethugepagesizes... no
checking for _Bool... yes
checking for stdbool.h that conforms to C99... yes
checking for inttypes.h... (cached) yes
checking for sys/auxv.h... yes
checking for sasl_callback_ft... no
checking for print macros for integers (C99 section 7.8.1)... yes
checking for an ANSI C-conforming const... yes
checking for socklen_t... yes
checking whether byte ordering is bigendian... no
checking for htonll... no
checking for library containing pthread_create... none required
checking for mlockall... yes
checking for getpagesizes... no
checking for sysconf... yes
checking for memcntl... no
checking for clock_gettime... yes
checking for preadv... yes
checking for pread... yes
checking for eventfd... yes
checking for accept4... yes
checking for getopt_long... yes
checking for alignment... none
checking for GCC atomics... yes
checking for GCC 64bit atomics... yes
checking for setppriv... no
checking for pledge... no
checking for cap_enter... no
checking for sandbox_init... no
checking for xml2rfc... no
checking for xsltproc... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating config.h
config.status: executing depfiles commands

After make, the outout of make test is:
./sizes
Slab Stats	64
Thread stats	2392
Global stats	208
Settings	368
Item (no cas)	48
Item (cas)	56
extstore header	12
Libevent thread	624
Connection	504
Response object	1184
Response bundle	24
Response objects per bundle	13
----------------------------------------
libevent thread cumulative	7112
Thread stats cumulative		6488
./testapp
1..56
ok 1 - cache_create
ok 2 - cache_reuse
ok 3 - cache_redzone
ok 4 - cache_limit_revised_downward
ok 5 - stats_prefix_find
ok 6 - stats_prefix_record_get
ok 7 - stats_prefix_record_delete
ok 8 - stats_prefix_record_set
ok 9 - stats_prefix_dump
ok 10 - issue_161
ok 11 - strtol
ok 12 - strtoll
ok 13 - strtoul
ok 14 - strtoull
ok 15 - issue_44
ok 16 - vperror
ok 17 - issue_101
ok 18 - crc32c
ok 19 - start_server
ok 20 - issue_92
ok 21 - issue_102
ok 22 - binary_noop
ok 23 - binary_quit
ok 24 - binary_quitq
ok 25 - binary_set
ok 26 - binary_setq
ok 27 - binary_add
ok 28 - binary_addq
ok 29 - binary_replace
ok 30 - binary_replaceq
ok 31 - binary_delete
ok 32 - binary_deleteq
ok 33 - binary_get
ok 34 - binary_getq
ok 35 - binary_getk
ok 36 - binary_getkq
ok 37 - binary_gat
ok 38 - binary_gatq
ok 39 - binary_gatk
ok 40 - binary_gatkq
ok 41 - binary_incr
ok 42 - binary_incrq
ok 43 - binary_decr
ok 44 - binary_decrq
ok 45 - binary_version
ok 46 - binary_flush
ok 47 - binary_flushq
ok 48 - binary_append
ok 49 - binary_appendq
ok 50 - binary_prepend
ok 51 - binary_prependq
ok 52 - binary_stat
ok 53 - binary_illegal
ok 54 - binary_pipeline_hickup
ok 55 - shutdown
ok 56 - stop_server
t/00-startup.t .............. 1/21 getaddrinfo(): Temporary failure in name resolution
failed to listen on one of interface(s) fooble: Resource temporarily unavailable
t/00-startup.t .............. 7/21 slab class   1: chunk size        96 perslab   10922
slab class   2: chunk size       120 perslab    8738
slab class   3: chunk size       152 perslab    6898
slab class   4: chunk size       192 perslab    5461
slab class   5: chunk size       240 perslab    4369
slab class   6: chunk size       304 perslab    3449
slab class   7: chunk size       384 perslab    2730
slab class   8: chunk size       480 perslab    2184
slab class   9: chunk size       600 perslab    1747
slab class  10: chunk size       752 perslab    1394
slab class  11: chunk size       944 perslab    1110
slab class  12: chunk size      1184 perslab     885
slab class  13: chunk size      1480 perslab     708
slab class  14: chunk size      1856 perslab     564
slab class  15: chunk size      2320 perslab     451
slab class  16: chunk size      2904 perslab     361
slab class  17: chunk size      3632 perslab     288
slab class  18: chunk size      4544 perslab     230
slab class  19: chunk size      5680 perslab     184
slab class  20: chunk size      7104 perslab     147
slab class  21: chunk size      8880 perslab     118
slab class  22: chunk size     11104 perslab      94
slab class  23: chunk size     13880 perslab      75
slab class  24: chunk size     17352 perslab      60
slab class  25: chunk size     21696 perslab      48
slab class  26: chunk size     27120 perslab      38
slab class  27: chunk size     33904 perslab      30
slab class  28: chunk size     42384 perslab      24
slab class  29: chunk size     52984 perslab      19
slab class  30: chunk size     66232 perslab      15
slab class  31: chunk size     82792 perslab      12
slab class  32: chunk size    103496 perslab      10
slab class  33: chunk size    129376 perslab       8
slab class  34: chunk size    161720 perslab       6
slab class  35: chunk size    202152 perslab       5
slab class  36: chunk size    252696 perslab       4
slab class  37: chunk size    315872 perslab       3
slab class  38: chunk size    394840 perslab       2
slab class  39: chunk size    524288 perslab       2
<26 server listening (auto-negotiate)
Exiting normally
slab class   1: chunk size        96 perslab   10922
slab class   2: chunk size       120 perslab    8738
slab class   3: chunk size       152 perslab    6898
slab class   4: chunk size       192 perslab    5461
slab class   5: chunk size       240 perslab    4369
slab class   6: chunk size       304 perslab    3449
slab class   7: chunk size       384 perslab    2730
slab class   8: chunk size       480 perslab    2184
slab class   9: chunk size       600 perslab    1747
slab class  10: chunk size       752 perslab    1394
slab class  11: chunk size       944 perslab    1110
slab class  12: chunk size      1184 perslab     885
slab class  13: chunk size      1480 perslab     708
slab class  14: chunk size      1856 perslab     564
slab class  15: chunk size      2320 perslab     451
slab class  16: chunk size      2904 perslab     361
slab class  17: chunk size      3632 perslab     288
slab class  18: chunk size      4544 perslab     230
slab class  19: chunk size      5680 perslab     184
slab class  20: chunk size      7104 perslab     147
slab class  21: chunk size      8880 perslab     118
slab class  22: chunk size     11104 perslab      94
slab class  23: chunk size     13880 perslab      75
slab class  24: chunk size     17352 perslab      60
slab class  25: chunk size     21696 perslab      48
slab class  26: chunk size     27120 perslab      38
slab class  27: chunk size     33904 perslab      30
slab class  28: chunk size     42384 perslab      24
slab class  29: chunk size     52984 perslab      19
slab class  30: chunk size     66232 perslab      15
slab class  31: chunk size     82792 perslab      12
slab class  32: chunk size    103496 perslab      10
slab class  33: chunk size    129376 perslab       8
slab class  34: chunk size    161720 perslab       6
slab class  35: chunk size    202152 perslab       5
slab class  36: chunk size    252696 perslab       4
slab class  37: chunk size    315872 perslab       3
slab class  38: chunk size    394840 perslab       2
slab class  39: chunk size    524288 perslab       2
<26 server listening (ascii)
t/00-startup.t .............. 15/21 Exiting normally
slab class   1: chunk size        96 perslab   10922
slab class   2: chunk size       120 perslab    8738
slab class   3: chunk size       152 perslab    6898
slab class   4: chunk size       192 perslab    5461
slab class   5: chunk size       240 perslab    4369
slab class   6: chunk size       304 perslab    3449
slab class   7: chunk size       384 perslab    2730
slab class   8: chunk size       480 perslab    2184
slab class   9: chunk size       600 perslab    1747
slab class  10: chunk size       752 perslab    1394
slab class  11: chunk size       944 perslab    1110
slab class  12: chunk size      1184 perslab     885
slab class  13: chunk size      1480 perslab     708
slab class  14: chunk size      1856 perslab     564
slab class  15: chunk size      2320 perslab     451
slab class  16: chunk size      2904 perslab     361
slab class  17: chunk size      3632 perslab     288
slab class  18: chunk size      4544 perslab     230
slab class  19: chunk size      5680 perslab     184
slab class  20: chunk size      7104 perslab     147
slab class  21: chunk size      8880 perslab     118
slab class  22: chunk size     11104 perslab      94
slab class  23: chunk size     13880 perslab      75
slab class  24: chunk size     17352 perslab      60
slab class  25: chunk size     21696 perslab      48
slab class  26: chunk size     27120 perslab      38
slab class  27: chunk size     33904 perslab      30
slab class  28: chunk size     42384 perslab      24
slab class  29: chunk size     52984 perslab      19
slab class  30: chunk size     66232 perslab      15
slab class  31: chunk size     82792 perslab      12
slab class  32: chunk size    103496 perslab      10
slab class  33: chunk size    129376 perslab       8
slab class  34: chunk size    161720 perslab       6
slab class  35: chunk size    202152 perslab       5
slab class  36: chunk size    252696 perslab       4
slab class  37: chunk size    315872 perslab       3
slab class  38: chunk size    394840 perslab       2
slab class  39: chunk size    524288 perslab       2
<26 server listening (binary)
<27 new binary client connection.
<27 connection closed.
Invalid value for binding protocol: http
 -- should be one of auto, binary, or ascii
Maximum connections must be greater than 0
Exiting normally
t/00-startup.t .............. 18/21 Maximum connections must be greater than 0
Number of threads must be greater than 0
t/00-startup.t .............. ok
t/64bit.t ................... ok
t/ascii-auth.t .............. ok
t/binary-extstore.t ......... ok
t/binary-get.t .............. ok
t/binary-sasl.t ............. This server is not built with SASL support.
t/binary-sasl.t ............. ok
t/binary.t .................. 1/? # Some chunked item tests
t/binary.t .................. ok
t/bogus-commands.t .......... ok
t/cas.t ..................... ok
t/chunked-extstore.t ........ ok
t/chunked-items.t ........... ok
t/conn-limits.t ............. ok
t/daemonize.t ............... ok
t/dash-M.t .................. ok
t/dyn-maxbytes.t ............ ok
t/error-extstore.t .......... ok
t/evictions.t ............... ok
t/expirations.t ............. ok
t/extstore-buckets.t ........ ok
t/extstore-jbod.t ........... ok
t/extstore-overdel.t ........ ok
t/extstore.t ................ supplied ext_path has zero size, cannot use
failed to parse ext_path argument
t/extstore.t ................ 1/? must supply size to ext_path, ie: ext_path=/f/e:64m (M|G|T|P supported)
failed to parse ext_path argument
Failed to initialize external storage: failed to open file
extstore open: Resource temporarily unavailable
t/extstore.t ................ ok
t/flags.t ................... ok
t/flush-all.t ............... ok
t/getandtouch.t ............. ok
t/getset.t .................. ok
t/idle-timeout.t ............ ok
t/incrdecr.t ................ ok
t/issue_104.t ............... ok
t/issue_108.t ............... ok
t/issue_14.t ................ ok
t/issue_140.t ............... skipped: Fix for Issue 140 was only an illusion
t/issue_152.t ............... ok
t/issue_163.t ............... ok
t/issue_183.t ............... ok
t/issue_192.t ............... ok
t/issue_22.t ................ ok
t/issue_260.t ............... skipped: Only possible to test #260 under artificial conditions
t/issue_29.t ................ ok
t/issue_3.t ................. ok
t/issue_41.t ................ ok
t/issue_42.t ................ ok
t/issue_50.t ................ ok
t/issue_61.t ................ ok
t/issue_67.t ................ ok
t/issue_68.t ................ ok
t/issue_70.t ................ ok
t/item_size_max.t ........... 1/7 Item max size cannot be less than 1024 bytes.
Cannot set item size limit higher than 1/2 of memory max.
t/item_size_max.t ........... ok
t/line-lengths.t ............ ok
t/lru-crawler.t ............. ok
t/lru-maintainer.t .......... ok
t/lru.t ..................... ok
t/malicious-commands.t ...... ok
t/maxconns.t ................ ok
t/metaget.t ................. 129/? # starting serve stale with mdelete
# running mdelete
# trying to fail then stale set via mset
# confirm item still stale, and TTL wasn't raised.
# do valid mset
# testing quiet flag
# now purposefully cause an error
# testing mget opaque
# flag and token count errors
# pipeline test
# mget + extstore tests
t/metaget.t ................. ok
t/misbehave.t ............... skipped: Privilege drop not supported
t/multiversioning.t ......... ok
t/noreply.t ................. ok
t/proxyantiflap.t ........... ok
t/proxyconfig.t ............. 1/? # testing failure to start
ERROR: Failed to load data into lua config state: /tmp/proxyconfigmode.lua:1: syntax error near 'syntax'
t/proxyconfig.t ............. ok
t/proxyinternal.t ........... ok
t/proxylimits.t ............. ok
t/proxyratelim.t ............ ok
t/proxyunits.t .............. ok
t/proxyustats.t ............. # testing failure to start
ERROR: Failed to load data into lua config state: /tmp/proxyustats.lua:1: syntax error near <eof>
t/proxyustats.t ............. 3/? ERROR: Failed to execute mcp_config_pools: stat index must be 1024 or less
t/proxyustats.t ............. 4/? ERROR: Failed to execute mcp_config_pools: stat index must be 1 or higher
t/proxyustats.t ............. 7/? ERROR: Failed to execute mcp_config_pools: stat name too long: ********************************************************************************************************************************1

t/proxyustats.t ............. ok
t/quit.t .................... ok
t/refhang.t ................. skipped: Test is flaky. Needs special hooks.
t/restart.t ................. [restart] Failed to read a tag from metadata file
t/restart.t ................. 1/? [restart] no metadata save file, starting with a clean cache
# restart basic stats
# Set some values, various sizes.
# load enough items to change hash power level
t/restart.t ................. 26/? # Load a couple chunked items
t/restart.t ................. 27/? # Data that should expire while stopped.
# killed, waiting
Gracefully stopping
# reconnected
t/restart.t ................. 52/? # low TTL item should be gone
t/restart.t ................. ok
t/shutdown.t ................ 4/? Gracefully stopping
t/shutdown.t ................ ok
t/slabhang.t ................ skipped: Test is flaky. Needs special hooks.
t/slabs-reassign-chunked.t .. ok
t/slabs-reassign2.t ......... ok
t/slabs_reassign.t .......... ok
t/ssl_cert_refresh.t ........ skipped: SSL testing is not enabled
t/ssl_ports.t ............... skipped: SSL testing is not enabled
t/ssl_proto_version.t ....... skipped: SSL testing is not enabled
t/ssl_session_resumption.t .. skipped: SSL testing is not enabled
t/ssl_settings.t ............ skipped: SSL testing is not enabled
t/ssl_verify_modes.t ........ skipped: SSL testing is not enabled
t/stats-conns.t ............. 9/12 PORT: 42079
t/stats-conns.t ............. ok
t/stats-detail.t ............ ok
t/stats.t ................... ok
t/strtol-testing.t .......... ok
t/touch.t ................... ok
t/udp.t ..................... ok
t/unixsocket.t .............. ok
t/watcher.t ................. ok
t/watcher_connid.t .......... ok
t/whitespace.t .............. skipped: Skipping test because this does not appear to be a memcached git working directory
All tests successful.
Files=89, Tests=177296, 405 wallclock secs ( 9.78 usr  1.04 sys + 18.17 cusr 15.10 csys = 44.09 CPU)
Result: PASS
File 'assoc.c' Lines executed:91.62% of 167 Creating 'assoc.c.gcov' File '/usr/include/stdlib.h' Lines executed:0.00% of 2 Creating 'stdlib.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:0.00% of 2 Creating 'stdio2.h.gcov' Lines executed:89.47% of 171
File 'authfile.c' Lines executed:88.00% of 50 Creating 'authfile.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:71.43% of 7 Creating 'stdio2.h.gcov' Lines executed:85.96% of 57
File 'base64.c' Lines executed:80.00% of 60 Creating 'base64.c.gcov' Lines executed:80.00% of 60
File 'bipbuffer.c' Lines executed:71.64% of 67 Creating 'bipbuffer.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:72.46% of 69
File 'cache.c' Lines executed:73.68% of 76 Creating 'cache.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:74.36% of 78
File 'crawler.c' Lines executed:75.62% of 447 Creating 'crawler.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/poll2.h' Lines executed:100.00% of 2 Creating 'poll2.h.gcov' Lines executed:75.71% of 457
File 'crc32c.c' Lines executed:50.26% of 191 Creating 'crc32c.c.gcov' Lines executed:50.26% of 191
File 'daemon.c' Lines executed:33.33% of 27 Creating 'daemon.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/fcntl2.h' Lines executed:100.00% of 5 Creating 'fcntl2.h.gcov' Lines executed:43.75% of 32
File 'extstore.c' Lines executed:88.41% of 535 Creating 'extstore.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/unistd.h' Lines executed:100.00% of 2 Creating 'unistd.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/fcntl2.h' Lines executed:100.00% of 5 Creating 'fcntl2.h.gcov' Lines executed:88.64% of 546
File 'hash.c' Lines executed:62.50% of 16 Creating 'hash.c.gcov' File 'xxhash.h' Lines executed:0.00% of 187 Creating 'xxhash.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/emmintrin.h' Lines executed:0.00% of 14 Creating 'emmintrin.h.gcov' Lines executed:4.61% of 217
File 'items.c' Lines executed:89.82% of 1081 Creating 'items.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 6 Creating 'string_fortified.h.gcov' Lines executed:89.73% of 1091
File 'itoa_ljust.c' Lines executed:78.57% of 56 Creating 'itoa_ljust.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:79.31% of 58
File 'jenkins_hash.c' Lines executed:68.82% of 93 Creating 'jenkins_hash.c.gcov' Lines executed:68.82% of 93
File 'logger.c' Lines executed:88.80% of 607 Creating 'logger.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:66.67% of 6 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 6 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/poll2.h' Lines executed:100.00% of 2 Creating 'poll2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/byteswap.h' Lines executed:0.00% of 2 Creating 'byteswap.h.gcov' Lines executed:88.44% of 623
File 'md5.c' Lines executed:0.00% of 120 Creating 'md5.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:0.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:0.00% of 122
File 'memcached.c' Lines executed:73.21% of 3109 Creating 'memcached.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:66.67% of 12 Creating 'stdio2.h.gcov' File '/usr/include/stdlib.h' Lines executed:100.00% of 2 Creating 'stdlib.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdlib-float.h' Lines executed:0.00% of 2 Creating 'stdlib-float.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/fcntl2.h' Lines executed:0.00% of 5 Creating 'fcntl2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/unistd.h' Lines executed:100.00% of 2 Creating 'unistd.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:80.00% of 10 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/byteswap.h' Lines executed:100.00% of 4 Creating 'byteswap.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/socket2.h' Lines executed:57.14% of 7 Creating 'socket2.h.gcov' Lines executed:73.07% of 3153
File 'murmur3_hash.c' Lines executed:100.00% of 37 Creating 'murmur3_hash.c.gcov' Lines executed:100.00% of 37
File 'proto_bin.c' Lines executed:68.38% of 759 Creating 'proto_bin.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/byteswap.h' Lines executed:100.00% of 4 Creating 'byteswap.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:68.53% of 769
File 'proto_proxy.c' Lines executed:75.20% of 621 Creating 'proto_proxy.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 6 Creating 'string_fortified.h.gcov' Lines executed:75.28% of 631
File 'proto_text.c' Lines executed:74.97% of 1726 Creating 'proto_text.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:74.94% of 1732
File 'proxy_await.c' Lines executed:90.98% of 244 Creating 'proxy_await.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:91.13% of 248
File 'proxy_config.c' Lines executed:80.08% of 251 Creating 'proxy_config.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:100.00% of 2 Creating 'stdio2.h.gcov' Lines executed:80.39% of 255
File 'proxy_internal.c' Lines executed:26.71% of 1007 Creating 'proxy_internal.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:27.00% of 1011
File 'proxy_jump_hash.c' Lines executed:100.00% of 21 Creating 'proxy_jump_hash.c.gcov' Lines executed:100.00% of 21
File 'proxy_lua.c' Lines executed:75.06% of 798 Creating 'proxy_lua.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 6 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:0.00% of 2 Creating 'stdio2.h.gcov' File 'xxhash.h' Lines executed:45.71% of 210 Creating 'xxhash.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/emmintrin.h' Lines executed:0.00% of 17 Creating 'emmintrin.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/xmmintrin.h' Lines executed:0.00% of 2 Creating 'xmmintrin.h.gcov' Lines executed:67.73% of 1035
File 'proxy_network.c' Lines executed:83.08% of 591 Creating 'proxy_network.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:0.00% of 2 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/socket2.h' Lines executed:57.14% of 7 Creating 'socket2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/unistd.h' Lines executed:100.00% of 2 Creating 'unistd.h.gcov' Lines executed:82.67% of 606
File 'proxy_ratelim.c' Lines executed:95.24% of 42 Creating 'proxy_ratelim.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:95.45% of 44
File 'proxy_request.c' Lines executed:90.32% of 444 Creating 'proxy_request.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:90.40% of 448
File 'proxy_ring_hash.c' Lines executed:3.59% of 167 Creating 'proxy_ring_hash.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:0.00% of 2 Creating 'stdio2.h.gcov' File 'xxhash.h' Lines executed:0.00% of 187 Creating 'xxhash.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/emmintrin.h' Lines executed:0.00% of 14 Creating 'emmintrin.h.gcov' Lines executed:1.62% of 370
File 'proxy_ustats.c' Lines executed:84.62% of 52 Creating 'proxy_ustats.c.gcov' Lines executed:84.62% of 52
File 'proxy_xxhash.c' Lines executed:100.00% of 3 Creating 'proxy_xxhash.c.gcov' File 'xxhash.h' Lines executed:0.00% of 205 Creating 'xxhash.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/emmintrin.h' Lines executed:0.00% of 17 Creating 'emmintrin.h.gcov' File '/usr/lib/gcc/x86_64-linux-gnu/11/include/xmmintrin.h' Lines executed:0.00% of 2 Creating 'xmmintrin.h.gcov' Lines executed:1.32% of 227
File 'restart.c' Lines executed:79.63% of 216 Creating 'restart.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:100.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/fcntl2.h' Lines executed:100.00% of 5 Creating 'fcntl2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio.h' Lines executed:100.00% of 2 Creating 'stdio.h.gcov' Lines executed:80.79% of 229
File 'slab_automove_extstore.c' Lines executed:76.36% of 110 Creating 'slab_automove_extstore.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:77.19% of 114
File 'slab_automove.c' Lines executed:96.39% of 83 Creating 'slab_automove.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:96.55% of 87
File 'slabs.c' Lines executed:88.07% of 679 Creating 'slabs.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 8 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' Lines executed:87.70% of 691
File 'stats_prefix.c' Lines executed:91.75% of 97 Creating 'stats_prefix.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:100.00% of 2 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 6 Creating 'string_fortified.h.gcov' Lines executed:92.38% of 105
File 'storage.c' Lines executed:81.14% of 827 Creating 'storage.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:50.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/stdlib.h' Lines executed:100.00% of 2 Creating 'stdlib.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 4 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/byteswap.h' Lines executed:100.00% of 2 Creating 'byteswap.h.gcov' Lines executed:81.17% of 839
File 'thread.c' Lines executed:78.80% of 533 Creating 'thread.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:0.00% of 2 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/unistd.h' Lines executed:100.00% of 2 Creating 'unistd.h.gcov' Lines executed:78.66% of 539
File 'util.c' Lines executed:96.88% of 128 Creating 'util.c.gcov' File '/usr/include/x86_64-linux-gnu/bits/stdio2.h' Lines executed:100.00% of 4 Creating 'stdio2.h.gcov' File '/usr/include/x86_64-linux-gnu/bits/string_fortified.h' Lines executed:100.00% of 2 Creating 'string_fortified.h.gcov' Lines executed:97.01% of 134

Finally
sudo make install

outputs:
make  install-recursive
make[1]: Entering directory '/home/negin/memcached-1.6.22'
Making install in doc
make[2]: Entering directory '/home/negin/memcached-1.6.22/doc'
make  install-am
make[3]: Entering directory '/home/negin/memcached-1.6.22/doc'
make[4]: Entering directory '/home/negin/memcached-1.6.22/doc'
make[4]: Nothing to be done for 'install-exec-am'.
 /usr/bin/mkdir -p '/usr/local/share/man/man1'
 /usr/bin/install -c -m 644 memcached.1 '/usr/local/share/man/man1'
make[4]: Leaving directory '/home/negin/memcached-1.6.22/doc'
make[3]: Leaving directory '/home/negin/memcached-1.6.22/doc'
make[2]: Leaving directory '/home/negin/memcached-1.6.22/doc'
Making install in vendor
make[2]: Entering directory '/home/negin/memcached-1.6.22/vendor'
make[2]: 'install' is up to date.
make[2]: Leaving directory '/home/negin/memcached-1.6.22/vendor'
make[2]: Entering directory '/home/negin/memcached-1.6.22'
make[3]: Entering directory '/home/negin/memcached-1.6.22'
 /usr/bin/mkdir -p '/usr/local/bin'
  /usr/bin/install -c memcached '/usr/local/bin'
 /usr/bin/mkdir -p '/usr/local/include/memcached'
 /usr/bin/install -c -m 644 protocol_binary.h xxhash.h '/usr/local/include/memcached'
make[3]: Leaving directory '/home/negin/memcached-1.6.22'
make[2]: Leaving directory '/home/negin/memcached-1.6.22'
make[1]: Leaving directory '/home/negin/memcached-1.6.22'

Now the server runs for the normal case (using memcached command) without a problem and I can set/get items and the results are fine as stats shows. But in the case of proxy servers, I have trouble. I use [simple.lua](https://github.com/memcached/memcached-proxylibs/blob/main/lib/simple.lua) and example.lua as below:
local s = require("simple")

-- by default, sends "/foo/*" to "foo" and "/bar/*" to "bar"
pool{
    name = "foo",
    backends = {"<IP_ADDRESS>:11212", "<IP_ADDRESS>:11213"},
}

pool{
    name = "bar",
    backends = {"<IP_ADDRESS>:11214", "<IP_ADDRESS>:11215"},
}

Then I run the server with proxy config set using example.lua:
LUA_PATH="./simple.lua" ./memcached -o proxy_config=./example.lua

Now the client connects to the server and the stats proxy, stats and stats settings are as follows:
negin@negin-virtual-machine:~$ telnet <IP_ADDRESS> 11211
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.
stats proxy
STAT user_simple_failovers 0
STAT active_req_limit 0
STAT buffer_memory_limit 0
STAT buffer_memory_used 0
STAT cmd_mg 0
STAT cmd_ms 0
STAT cmd_md 0
STAT cmd_mn 0
STAT cmd_ma 0
STAT cmd_me 0
STAT cmd_get 0
STAT cmd_gat 0
STAT cmd_set 0
STAT cmd_add 0
STAT cmd_cas 0
STAT cmd_gets 0
STAT cmd_gats 0
STAT cmd_incr 0
STAT cmd_decr 0
STAT cmd_touch 0
STAT cmd_append 0
STAT cmd_prepend 0
STAT cmd_delete 0
STAT cmd_replace 0
END
stats
STAT pid 12816
STAT uptime 78
STAT time<PHONE_NUMBER>
STAT version 1.6.22
STAT libevent 2.1.12-stable
STAT pointer_size 64
STAT rusage_user 0.010517
STAT rusage_system 0.021035
STAT max_connections 1024
STAT curr_connections 2
STAT total_connections 3
STAT rejected_connections 0
STAT connection_structures 3
STAT response_obj_oom 0
STAT response_obj_count 1
STAT response_obj_bytes 16384
STAT read_buf_count 2
STAT read_buf_bytes 32768
STAT read_buf_bytes_free 0
STAT read_buf_oom 0
STAT reserved_fds 20
STAT proxy_conn_requests 0
STAT proxy_conn_errors 0
STAT proxy_conn_oom 0
STAT proxy_req_active 0
STAT proxy_await_active 0
STAT cmd_get 0
STAT cmd_set 0
STAT cmd_flush 0
STAT cmd_touch 0
STAT cmd_meta 0
STAT get_hits 0
STAT get_misses 0
STAT get_expired 0
STAT get_flushed 0
STAT delete_misses 0
STAT delete_hits 0
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT store_too_large 0
STAT store_no_memory 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 20
STAT bytes_written 449
STAT limit_maxbytes 67108864
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT time_in_listen_disabled_us 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT slab_reassign_rescues 0
STAT slab_reassign_chunk_rescues 0
STAT slab_reassign_evictions_nomem 0
STAT slab_reassign_inline_reclaim 0
STAT slab_reassign_busy_items 0
STAT slab_reassign_busy_deletes 0
STAT slab_reassign_running 0
STAT slabs_moved 0
STAT lru_crawler_running 0
STAT lru_crawler_starts 2
STAT lru_maintainer_juggles 128
STAT malloc_fails 0
STAT log_worker_dropped 0
STAT log_worker_written 0
STAT log_watcher_skipped 0
STAT log_watcher_sent 0
STAT log_watchers 0
STAT proxy_config_reloads 1
STAT proxy_config_reload_fails 0
STAT proxy_backend_total 4
STAT proxy_backend_marked_bad 4
STAT proxy_backend_failed 12
STAT unexpected_napi_ids 0
STAT round_robin_fallback 0
STAT bytes 0
STAT curr_items 0
STAT total_items 0
STAT slab_global_page_pool 0
STAT expired_unfetched 0
STAT evicted_unfetched 0
STAT evicted_active 0
STAT evictions 0
STAT reclaimed 0
STAT crawler_reclaimed 0
STAT crawler_items_checked 0
STAT lrutail_reflocked 0
STAT moves_to_cold 0
STAT moves_to_warm 0
STAT moves_within_lru 0
STAT direct_reclaims 0
STAT lru_bumps_dropped 0
END
stats settings
STAT maxbytes 67108864
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 0
STAT inter NULL
STAT verbosity 0
STAT oldest 0
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT shutdown_command no
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT num_threads_per_udp 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol proxy
STAT auth_enabled_sasl no
STAT auth_enabled_ascii no
STAT item_size_max 1048576
STAT maxconns_fast yes
STAT hashpower_init 0
STAT slab_reassign yes
STAT slab_automove 1
STAT slab_automove_ratio 0.80
STAT slab_automove_window 30
STAT slab_chunk_max 524288
STAT lru_crawler yes
STAT lru_crawler_sleep 100
STAT lru_crawler_tocrawl 0
STAT tail_repair_time 0
STAT flush_enabled yes
STAT dump_enabled yes
STAT hash_algorithm murmur3
STAT lru_maintainer_thread yes
STAT lru_segmented yes
STAT hot_lru_pct 20
STAT warm_lru_pct 40
STAT hot_max_factor 0.20
STAT warm_max_factor 2.00
STAT temp_lru no
STAT temporary_ttl 61
STAT idle_timeout 0
STAT watcher_logbuf_size 262144
STAT worker_logbuf_size 65536
STAT read_buf_mem_limit 0
STAT track_sizes no
STAT inline_ascii_response no
STAT ext_item_size 512
STAT ext_item_age<PHONE_NUMBER>
STAT ext_low_ttl 0
STAT ext_recache_rate 2000
STAT ext_wbuf_size 4194304
STAT ext_compact_under 0
STAT ext_drop_under 0
STAT ext_max_sleep 1000000
STAT ext_max_frag 0.80
STAT slab_automove_freeratio 0.010
STAT ext_drop_unread no
STAT proxy_enabled yes
STAT proxy_uring_enabled no
STAT num_napi_ids (null)
STAT memory_file (null)
STAT client_flags_size 4
END

From this, I can say that the proxy has been enabled successfully. But when I try to set items in the server I get errors:
set /foo/key1 0 1000 4
1234
SERVER_ERROR backend failure
set key1 0 100 4
1234
SERVER_ERROR no route
set /bar/key1 0 1000 4
1234
SERVER_ERROR backend failure
get /foo/key2
SERVER_ERROR backend failure

And the output of stats proxy after these unsuccessful attempts is
STAT user_simple_failovers 0
STAT active_req_limit 0
STAT buffer_memory_limit 0
STAT buffer_memory_used 0
STAT cmd_mg 0
STAT cmd_ms 0
STAT cmd_md 0
STAT cmd_mn 0
STAT cmd_ma 0
STAT cmd_me 0
STAT cmd_get 1
STAT cmd_gat 0
STAT cmd_set 3
STAT cmd_add 0
STAT cmd_cas 0
STAT cmd_gets 0
STAT cmd_gats 0
STAT cmd_incr 0
STAT cmd_decr 0
STAT cmd_touch 0
STAT cmd_append 0
STAT cmd_prepend 0
STAT cmd_delete 0
STAT cmd_replace 0
END

while these failed cmds are not included in the stats under cmd_set or cmd_get (instead it is counted under proxy_conn_requests which is 4):
stats
STAT pid 12816
STAT uptime 433
STAT time<PHONE_NUMBER>
STAT version 1.6.22
STAT libevent 2.1.12-stable
STAT pointer_size 64
STAT rusage_user 0.035483
STAT rusage_system 0.106451
STAT max_connections 1024
STAT curr_connections 2
STAT total_connections 3
STAT rejected_connections 0
STAT connection_structures 3
STAT response_obj_oom 0
STAT response_obj_count 1
STAT response_obj_bytes 16384
STAT read_buf_count 2
STAT read_buf_bytes 32768
STAT read_buf_bytes_free 0
STAT read_buf_oom 0
STAT reserved_fds 20
STAT proxy_conn_requests 4
STAT proxy_conn_errors 0
STAT proxy_conn_oom 0
STAT proxy_req_active 0
STAT proxy_await_active 0
STAT cmd_get 0
STAT cmd_set 0
STAT cmd_flush 0
STAT cmd_touch 0
STAT cmd_meta 0
STAT get_hits 0
STAT get_misses 0
STAT get_expired 0
STAT get_flushed 0
STAT delete_misses 0
STAT delete_hits 0
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT store_too_large 0
STAT store_no_memory 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 155
STAT bytes_written 5186
STAT limit_maxbytes 67108864
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT time_in_listen_disabled_us 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT slab_reassign_rescues 0
STAT slab_reassign_chunk_rescues 0
STAT slab_reassign_evictions_nomem 0
STAT slab_reassign_inline_reclaim 0
STAT slab_reassign_busy_items 0
STAT slab_reassign_busy_deletes 0
STAT slab_reassign_running 0
STAT slabs_moved 0
STAT lru_crawler_running 0
STAT lru_crawler_starts 4
STAT lru_maintainer_juggles 482
STAT malloc_fails 0
STAT log_worker_dropped 0
STAT log_worker_written 0
STAT log_watcher_skipped 0
STAT log_watcher_sent 0
STAT log_watchers 0
STAT proxy_config_reloads 1
STAT proxy_config_reload_fails 0
STAT proxy_backend_total 4
STAT proxy_backend_marked_bad 4
STAT proxy_backend_failed 12
STAT unexpected_napi_ids 0
STAT round_robin_fallback 0
STAT bytes 0
STAT curr_items 0
STAT total_items 0
STAT slab_global_page_pool 0
STAT expired_unfetched 0
STAT evicted_unfetched 0
STAT evicted_active 0
STAT evictions 0
STAT reclaimed 0
STAT crawler_reclaimed 0
STAT crawler_items_checked 0
STAT lrutail_reflocked 0
STAT moves_to_cold 0
STAT moves_to_warm 0
STAT moves_within_lru 0
STAT direct_reclaims 0
STAT lru_bumps_dropped 0
END

I have also tried a watcher process but it does not print anything for proxy requests.
I tried to trace back the backend failure error and it comes from proto_proxy.c:620:
int proxy_run_coroutine(lua_State *Lc, mc_resp *resp, io_pending_proxy_t *p, conn *c) {
    int nresults = 0;
    int cores = lua_resume(Lc, NULL, 1, &nresults);
    size_t rlen = 0;

    if (cores == LUA_OK) {
        WSTAT_DECR(c->thread, proxy_req_active, 1);
        int type = lua_type(Lc, 1);
        P_DEBUG("%s: coroutine completed. return type: %d\n", __func__, type);
        if (type == LUA_TUSERDATA) {
            mcp_resp_t *r = luaL_checkudata(Lc, 1, "mcp.response");
            _set_noreply_mode(resp, r);
            if (r->status != MCMC_OK && r->resp.type != MCMC_RESP_ERRMSG) {
                proxy_out_errstring(resp, PROXY_SERVER_ERROR, "backend failure"); // <========= line 620
            } else if (r->cresp) {
.
.
.
.
.

But the reason is not obvious to me. I don't know why is this happening and what is wrong.

Hi! Thanks for the detailed outputs. 1.6.22 is probably fine to use right now.
Apologies if this is an obvious question but did you start other memcached's on localhost? Your configuration shows the proxy should be talking to four servers listening on localhost on a couple ports (11212/3/4/5) but I don't see you make any mention of starting those servers.
backend failure means the backend was unreachable for some reason. If you start the proxy you should see it connect to the other memcached's behind it (via stats conns or starting them with -vvv). They should connect and run a version command.
watch proxyevents should print outputs when a backend goes down, but it might not show anything if the backends are down when you first start the proxy.
Sorry for the weird user experience. I'm still working on a bunch of changes to make this easier on folks.

Thank you, problem solved. I had not started 11212/3/4/5 servers separately and assumed that the proxy server is going to handle it during configuration.
For the watchers and stats, I still have to query each server separately since the proxy does not show hits or misses per server, and its watcher does not synchronously output the events (I tried proxyevents and proxyreqs). It is like the proxy is not fully abstracting us away from the pools of servers.

The focus of the proxy is mostly performance, because otherwise it would be difficult for people to deploy it in front of an existing cache cluster. So it doesn't do some things like track detailed per-backend stats (the backends themselves already have comprehensive stats). It's more about routing traffic than managing/detailing data.
If you add log = true to one of your pool configs you should start seeing immediate queries in watch proxyreqs
Also you do need to manage backends. If your backend nodes are on different hosts it would have to ssh in and start/stop things, which it can't reasonably do on its own. You should use your existing server management (kubes or whatever) for that.
The proxy is useful in abstracting different memcached clusters from the perspective of your application client. IE: Your client sees one cache host and issues queries against it, and the proxy splits that traffic into different clusters as necessary. Then you can resize and add/remove clusters without changing your clients.
It's also highly flexible so advanced users can basically write their own simple.lua and decide how to handle and log traffic in a way that matches what their corporation needs.


Markdown fix.

Hugo v0.37 fails to recognize bulleted list without blank line:
https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/

Thanks for this, @mgolosova!


Importing large models can crash Blender

When importing large models, Blender can freeze and it either eventually loads, or never does and I have to close Blender, so I kind of have to guess the limit of the amount of cubes I can import at a time. I know I can split the voxels into separate objects and import them as separate files but that kinda works against Greedy Meshing. Is there is a way to circumvent this issue that I'm not aware of?
Either way, I just wanted to say that I have no idea why this isn't the most recommended Voxel add-on for Blender and I'm super thankful. Preserving Material IDs while using Greedy Meshing is something that's essential to my current project and I was almost convinced no one has made a tool that combined both. This is incredible!

Thank you very much for your kind words!
When you say large models, can you tell me how large you mean? Blender is sadly somewhat slow in some parts, especially when importing individual cubes, but from your description i guess you use the greedy meshing mode.
I will investigate what may be improved and also try to find a solution for blender not to freeze and maybe show a progress bar (the importer is still running in the background when blender freezes and will eventually finish).
If you are willing, it would be easier to test if you could provide me with a vox file that caused the problem.

Yeah, my models are BIG. My current limit is 255 cubed. The project I'm currently using should feature Occlusion Culling, so for the moment I actually kind of benefit from splitting my models into parts. I also found even the huge models eventually load, unlike RichysHub's addon.
Here is the file:
Chateau.zip

I tested your file and did some research on the window freezing issue. Sadly this is a big issue with blender python addons that the window will freeze and be unresponsive for long tasks and there is currently no great way to provide feedback such as a progress bar to the user, sorry.
However, i took the opportunity to replace the internal data structure of the voxels with a proper one (i had this on my todo list for quite some time). The greedy meshed loading time on my machine for your Chateau got reduced from 530 seconds to 158 seconds which i'm quite happy with :)
I created a new release just now, feel free to download and test it for yourself. I tested it with a variety of models and all seems fine, but with such big changes you never know. So please let me know it there is something wrong!

That's great! I'm quite happy with that, thank you


Fix ruby_source_path in Ventura systemsettings-caveats fixture JSON

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Cask source paths were added to the API in 844db75361. The main everything.json file was updated with the new data in that commit, but this one was missed causing local test failures.

Before:
Cask::Cask#to_h when loaded from cask file returns expected hash
  Failure/Error: expect(JSON.pretty_generate(hash)).to eq(expected_json_after_ventura)
    [...]

    Diff:
    @@ -93,7 +93,7 @@
        "en",
        "eo"
      ],
    -  "ruby_source_path": "Formula/everything.rb",
    +  "ruby_source_path": "Casks/everything.rb",
      "ruby_source_checksum": {
        "sha256": "b2707d1952f02c3fa566b7ad2a707a847a959d36f51d3dee642dbe5deec12f27"
      }

  # ./test/cask/cask_spec.rb:231:in `block (4 levels) in <top (required)>'
  # ./test/support/helper/spec/shared_context/homebrew_cask.rb:52:in `block (2 levels) in <top (required)>'

The test for this should also be changed to stub MacOS.version instead of depending on which system you run it on.


Implicit route binding with UrlRoutable only

This is an improvement on https://github.com/laravel/framework/pull/20521
Although @GrahamCampbell is wrong in https://github.com/laravel/framework/pull/20535 about UrlRoutable's dependence on eloquent, he has a point in a way little bit different.
He's right about that UrlRoutable@resolveRouteBinding should be able to return anything, not just eloquent. There's no restriction in the interface itself, however there are restrictions in other parts of the framework.
This PR replaces checks of Model with checks of UrlRoutable in ImplicitRouteBinding.
From now the following is possible:
Route::get('/posts/{post}', function(\App\Post $post){
	return $post->id;
});

<?php

namespace App;

class Post implements \Illuminate\Contracts\Routing\UrlRoutable
{
    public $id;

    public function getRouteKey(){
    	return $this->id;
    }

    public function getRouteKeyName(){
    	return 'id';
    }

    public function resolveRouteBinding($id){
    	$post = new Post;

    	$post->id = $id;

    	return $post;
    }
}

Now this Post model implements ImplicitRouteBinding and resolveRouteBinding clearly doesn't return eloquent!

Although @GrahamCampbell is wrong in #20535 about UrlRoutable's dependence on eloquent

No I'm not. This references a class from eloquent, thus there is a dependency...
    /**
     * Retrieve the model for a bound value.
     *
     * @param  mixed  $value
     * @return \Illuminate\Database\Eloquent\Model|null
     */
    public function resolveRouteBinding($value);

I forgot to replace that, one moment.

@GrahamCampbell Now?

Fixes the dependency problem, yeh. 👍

There are implicit binding related things in Illuminate\Broadcasting\Broadcasters\Broadcaster too, having the same logic now moved to UrlRoutable@resolveRouteBinding.
@GrahamCampbell Is this implicit binding same as implicit route model binding? I'm asking because I'm not familiar with broadcasters. If so, I'll refactor this class as well.

We're not changing anything else about this and the parameter name $routeKey doesn't make sense.


x/pkgsite: const block comment not rendered in some cases

What is the URL of the page with the issue?
https://pkg.go.dev/github.com/reddit/baseplate.go@v0.0.0-20200427171913-839af98823fe/httpbp?tab=doc#pkg-constants, the first const block
What did you expect to see?
The code actually have comments on them, but they are not rendered in go.dev.
One thing to note is that they are not rendered on godoc.org either. I think it might has something to do with the long string const?

/cc @dmitshur

Thanks for reporting.
This is due to a limitation of the algorithm used to trim excessively large string literals and slices (see relevant code here). Documentation rendering on pkg.go.dev used the same algorithm as on godoc.org, so it was equally affected.
I've looked into it, and it is possible to resolve this issue. I'll send a fix.

This is fixed for this package, but see #42425 for ongoing (minor) formatting issues.


Added hmpps auth mock for SP user pact tests.

Added hmpps auth mock for SP user pact tests. Hmpps.getUserGroups now returns HAPPY_LIVING as default

🙋♂ I think the pull request template would be useful for anyone reading this later -- when we have a bit of time, could we fill the description according to that, please?


Error building demo

I am trying to build on an M2 Max.
➜  zap git:(master) zig version; sw_vers; clang --version
0.11.0-dev.3177+e584dd806
ProductName:		macOS
ProductVersion:		13.3.1
ProductVersionExtra:	(a)
BuildVersion:		22E772610a
Homebrew clang version 16.0.3
Target: arm64-apple-darwin22.4.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
➜  zap git:(master) git log -1 | tee
commit 6e3c9805164acfe7be57f687712ab87e49314e8d
Author: Rene Schallner<EMAIL_ADDRESS>Date:   Tue May 16 04:47:08 2023 +0200

    Update README.md

➜  zap git:(master) zig build run-hello
thread 824141 panic: @memcpy arguments have non-equal lengths
/Users/jonas/src/zig/zig/lib/std/crypto/tls/Client.zig:1062:25: 0x1032934ef in readvAdvanced__anon_149392 (zig)
            @memcpy(frag[0..in], first);
                        ^
/Users/jonas/src/zig/zig/lib/std/crypto/tls/Client.zig:898:38: 0x1032914a3 in readvAtLeast__anon_149391 (zig)
        var amt = try c.readvAdvanced(stream, iovecs[vec_i..]);
                                     ^
/Users/jonas/src/zig/zig/lib/std/crypto/tls/Client.zig:859:24: 0x103291287 in readAtLeast__anon_149390 (zig)
    return readvAtLeast(c, stream, &iovecs, len);
                       ^
/Users/jonas/src/zig/zig/lib/std/crypto/tls/Client.zig:864:23: 0x1032911a7 in read__anon_149389 (zig)
    return readAtLeast(c, stream, buffer, 1);
                      ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:173:41: 0x102d9ce77 in read (zig)
            .tls => conn.tls_client.read(conn.stream, buffer),
                                        ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:267:42: 0x102af5be3 in fill (zig)
        const nread = try bconn.conn.read(bconn.read_buf[0..]);
                                         ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:302:27: 0x102d9d75b in readAtLeast (zig)
            try bconn.fill();
                          ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:309:33: 0x102af5f37 in read (zig)
        return bconn.readAtLeast(buffer, 1);
                                ^
/Users/jonas/src/zig/zig/lib/std/http/protocol.zig:586:53: 0x102af5517 in read__anon_105152 (zig)
                        const nread = try bconn.read(buffer[out_index..][0..can_read]);
                                                    ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:682:53: 0x102af6c47 in transferRead (zig)
            const amt = try req.response.parser.read(&req.connection.data.buffered, buf[index..], req.response.skip);
                                                    ^
/Users/jonas/src/zig/zig/lib/std/http/Client.zig:812:41: 0x102afdeef in read (zig)
            else => try req.transferRead(buffer),
                                        ^
/Users/jonas/src/zig/zig/lib/std/io/reader.zig:27:26: 0x102aff583 in read (zig)
            return readFn(self.context, buffer);
                         ^
/Users/jonas/src/zig/zig/lib/std/io/buffered_reader.zig:27:62: 0x102aff30b in read (zig)
                    const n = try self.unbuffered_reader.read(self.buf[0..]);
                                                             ^
/Users/jonas/src/zig/zig/lib/std/io/reader.zig:27:26: 0x102aff773 in read (zig)
            return readFn(self.context, buffer);
                         ^
/Users/jonas/src/zig/zig/lib/std/io/reader.zig:243:43: 0x102db3d07 in readByte (zig)
            const amt_read = try self.read(result[0..]);
                                          ^
/Users/jonas/src/zig/zig/lib/std/compress/deflate/decompressor.zig:848:55: 0x102db45b3 in huffSym (zig)
                    var c = self.inner_reader.readByte() catch |e| {
                                                      ^
/Users/jonas/src/zig/zig/lib/std/compress/deflate/decompressor.zig:621:49: 0x102b01a7b in huffmanBlock (zig)
                        var v = try self.huffSym(self.hl.?);
                                                ^
/Users/jonas/src/zig/zig/lib/std/compress/deflate/decompressor.zig:471:26: 0x102b05073 in read (zig)
                self.step(self) catch |e| {
                         ^
/Users/jonas/src/zig/zig/lib/std/compress/gzip.zig:128:45: 0x102b047af in read (zig)
            const r = try self.inflater.read(buffer);
                                            ^
/Users/jonas/src/zig/zig/lib/std/io/reader.zig:27:26: 0x102b0513f in read (zig)
            return readFn(self.context, buffer);
                         ^
/Users/jonas/src/zig/zig/lib/std/io/reader.zig:46:42: 0x1028cbf8b in readAtLeast (zig)
                const amt = try self.read(buffer[index..]);
                                         ^
/Users/jonas/src/zig/zig/lib/std/tar.zig:153:50: 0x1028cb743 in pipeToFileSystem__anon_49750 (zig)
                    end += try reader.readAtLeast(buffer[end..], ask);
                                                 ^
/Users/jonas/src/zig/zig/src/Package.zig:589:33: 0x1028cc27b in unpackTarball__anon_49516 (zig)
    try std.tar.pipeToFileSystem(out_dir, decompress.reader(), .{
                                ^
/Users/jonas/src/zig/zig/src/Package.zig:508:30: 0x1028ddde7 in fetchAndUnpack (zig)
            try unpackTarball(gpa, &req, tmp_directory.handle, std.compress.gzip);
                             ^
/Users/jonas/src/zig/zig/src/Package.zig:283:43: 0x1028e53b7 in fetchAndAddDependencies (zig)
        const sub_pkg = try fetchAndUnpack(
                                          ^
/Users/jonas/src/zig/zig/src/main.zig:4402:67: 0x10273ba3b in cmdBuild (zig)
            const fetch_result = build_pkg.fetchAndAddDependencies(
                                                                  ^
/Users/jonas/src/zig/zig/src/main.zig:299:24: 0x102708f6f in mainArgs (zig)
        return cmdBuild(gpa, arena, cmd_args);
                       ^
/Users/jonas/src/zig/zig/src/main.zig:212:20: 0x102707b13 in main (zig)
    return mainArgs(gpa, arena, args);
                   ^
/Users/jonas/src/zig/zig/lib/std/start.zig:609:37: 0x10270a08f in main (zig)
            const result = root.main() catch |err| {
                                    ^
???:?:?: 0x18bab3f27 in ??? (???)
???:?:?: 0x6d02ffffffffffff in ??? (???)
[1]    76209 abort      /Users/jonas/src/zig/zig/build/stage3/bin/zig build run-hello
➜

Other people seem to have similar problems, see thiss issue

Please use release-0.0.20-localhost. This references its dependencies on localhost to work around current Zig master's TLS bug when fetching from GitHub.
$ # get dependency required by zap
$ wget https://github.com/zigzap/facil.io/archive/refs/tags/zap-0.0.8.tar.gz
$ # get zap itself
$ wget https://github.com/zigzap/zap/archive/refs/tags/release-0.0.20-localhost.tar.gz
$ # start a http server on port 8000
$ python -m http.server

This hosts the downloaded dependencies locally on port 8000. After the firstzig build, you can stop the python http server with CTRL+C.
If you want to build the examples, you don't need to download the ZAP tar.gz, you only need the facil.io dependency.

std.crypto.tls and std.http etc are all parts of the Zig standard library. Zap does not use them. So please, join in on ziglang/zig#15990.

I've created a dedicated doc for this issue and also linked to it in the readme.
I will leave this issue open, hoping it might help other people encountering similar problems.

Thanks, I'll try the localhost workaround. Hope the upstream issue gets sorted out, I like the simplicity of what your trying to do with zap.

Update! According to the commit log, Andrew fixed the underlying TLS bug about 14h ago. Unfortunately, it didn't make it into the current nightly build. But from tomorrow (CI server time) on, this bug should be history!
Will close this issue after I have validated the fix on my side.

Nice! Building and running zap master works without workarounds today.

Closing it as zig is fixed now. Feel free to re-open if you think this is a mistake :relaxed:

I tested cloning master and running on an Intel Mac and on a Pi400 running Manjaro, too. "zig build run-hello" works out-of-the-box, this is definitely fixed. :-)

Oh, this is a totally forgotten project. Using the zig std HTTP server that keeps on changing. I'll have a look and include in the build_all schript so it gets checked by CI as well.

OK, I fixed it. Will push shortly. Won't make a release for it tho, as it's not zap per se that's modified.

fixed in 0c18565


[BUG]<EMAIL_ADDRESS><EMAIL_ADDRESS>"add")  Status 500

Not using proxy;
Not using server;
Saved credentials;
Rest of the code works.
I'm testing a new feature to deploy in a project with the following code:
if (message && message.startsWith("$teste")) {

      const numero = message.split(" ")[1] +<EMAIL_ADDRESS>      console.log(numero);

      await socket
<EMAIL_ADDRESS><EMAIL_ADDRESS>"add")
        .then((data) => console.log(data))
        .catch((data) => console.log(data));
    }

Console output:
<EMAIL_ADDRESS>Error: bad-request
    at assertNodeErrorFree (/home/gkigor/Development/testes/migrate-baileys-teste/node_modules/.pnpm/@whiskeysockets+baileys@6.5.0_qrcode-terminal@0.12.0/node_modules/@whiskeysockets/baileys/lib/WABinary/generic-utils.js:56:15)
    at query (/home/gkigor/Development/testes/migrate-baileys-teste/node_modules/.pnpm/@whiskeysockets+baileys@6.5.0_qrcode-terminal@0.12.0/node_modules/@whiskeysockets/baileys/lib/Socket/socket.js:140:48)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Object.groupParticipantsUpdate (/home/gkigor/Development/testes/migrate-baileys-teste/node_modules/.pnpm/@whiskeysockets+baileys@6.5.0_qrcode-terminal@0.12.0/node_modules/@whiskeysockets/baileys/lib/Socket/groups.js:142:28) {
  data: 400,
  isBoom: true,
  isServer: true,
  output: {
    statusCode: 500,
    payload: {
      statusCode: 500,
      error: 'Internal Server Error',
      message: 'An internal server error occurred'
    },
    headers: {}
  }
}

In short, I want to add members to a group, but an internal server error occurred.

Have you checked if the number you want to add is allowed for everyone to add to the group?

No, do I need verification? Do you have a code example?

Hey
I was testing around with this code.  What I found regarding this. If you have one number that isn't tied to WhatsApp account, it causes the entire request to fail.
So assuming you have [, ] as participants the entire request fails. I'd expect it to fail with like 404 for that number but not the entire request.


Which Pascal?

There's Delphi (Borland Pascal), Lazarus (Free Pascal), GNU Pascal, Turbo Pascal, UCSD Pascal, Object Pascal, the list goes on and on. It would be nice to know which implementation is used, and talk about how to get it in INSTALLATION.md.
Also, I can't make an icon until I know which distribution this is using, because I can't read Pascal and so I don't know what kind the current code in the PRs is.

I have been using Delphi XE5 (Embarcadero) with DUnitX as my test framework.  DUnitX is compatible with Delphi 2010 through the most recent release of Delphi.
I only have a passing familiarity with FPC/Lazarus.  I don't know that DUnitX would be fully compatible.
Sent from my android device.
-----Original Message-----
From: cat<EMAIL_ADDRESS>To: exercism/xpascal<EMAIL_ADDRESS>Sent: Tue, 08 Nov 2016 3:07 PM
Subject: [exercism/xpascal] Which Pascal? (#23)
There's Delphi (Borland Pascal), Lazarus (Free Pascal), GNU Pascal, Turbo Pascal, UCSD Pascal, Object Pascal, the list goes on and on. It would be nice to know which implementation is used, and talk about how to get it in INSTALLATION.md.
Also, I can't make an icon until I know which distribution this is using.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/exercism/xpascal/issues/23

Icon has been created and merged to master.  Also issue #45 is discussing renaming track to Delphi Pascal and perhaps creating a "Sister" Object Pascal track that would be suited for Free Pascal/Lazarus.

Closing as I think the Icon has been chosen to be Blaise Pascal.


Opening a file with ctrl+p sometimes fails to render the text of the file

VSCode Version: 1.29.0-insider
OS Version: Windows 10

Steps to Reproduce:

press ctrl+p
choose a file to open
file name appears on new tab, but (sometimes) no text in the file is rendered.
closing and re-opening the window does not resolve the issue.
opening the file from the sidebar explorer results in two tabs titled filename but only the one opened from the sidebar will render text.

Does this issue occur when all extensions are disabled?: Yes

Yeah that fixes it. Thanks!


support edit grammar with parser errors in the expanded/pop-up lambda editor

Summary

support edit grammar with parser errors in the expanded/pop-up lambda editor
How did you test this change?

[ ] Test(s) added
[x] Manual testing (please provide screenshots/recordings)
[ ] No testing (please provide an explanation)

https://github.com/finos/legend-studio/assets/73408381/12091ddc-4b53-4a63-9a79-2735f06a035f

@YannanGao-gs can we look into adding/enhancing tests into LambaEditor? We have mocking for Monaco Editor which should make this easier.

I haven't found any test in the codebase for testing LambaEditor yet. Should we create a new issue to enhance test of LambaEditor or you prefer to do it in this PR

@YannanGao-gs can we look into adding/enhancing tests into LambaEditor? We have mocking for Monaco Editor which should make this easier.

I haven't found any test in the codebase for testing LambaEditor yet. Should we create a new issue to enhance test of LambaEditor or you prefer to do it in this PR
Besides, Would you mind being more specific about what features should be tested? Thanks

lets try and do it in this PR if it seems we need to mock a lot of stuff etc, we can shift to another issue


package.json not valid for bash

In Bash one set environment variables using the "export" command "set" is used to set internal Bash variables.
Since set is used in some other shells and Windows one should consider either making the script OS aware, or advise a different shell.
As a workaround one can set the variable manually prior to running npm e.g. "export NODE_ENV=development"
The answers here offer a couple options: https://stackoverflow.com/questions/45082648/npm-package-json-os-specific-script.
"scripts": {
    "build": "webpack -p",
    "start": "set NODE_ENV=production && node --no-deprecation ./dist/index.js ",
    "webpack-dev": "set NODE_ENV=development && webpack && node --no-deprecation ./dist/index.js",
    "dev": "set NODE_ENV=development && nodemon --exec babel-node --no-deprecation src/index.js"
  },

Yeah, nice catch. I had the issue and was working on installing cross-env and changing the script. I couldn’t make it work (or maybe I was too tired to understand). Anyway, I’ll try changing that soon. Also, if you have a better solution (or you’re faster than me), pull request are welcomed !


Flipper::Adapters::Strict::NotFound raised when checking non-existant feature flag during rspec test

The following error is being raised when a class under test is checking if a feature toggle exists:
Flipper::Adapters::Strict::NotFound: Could not find feature "some_feature". Call `Flipper.add("some_feature")` to create it.

I believe this is being caused by a bug in the flipper_configure method within test_help.rb:
def flipper_configure
  # Use a shared Memory adapter for all tests. This is instantiated outside of the
  # `configure` block so the same instance is returned in new threads.
  adapter = Flipper::Adapters::Memory.new

  Flipper.configure do |config|
    config.adapter { adapter }
    config.default { Flipper.new(config.adapter) }
  end
end

The code above should not be calling config.adapter when initializing Flipper. Instead, it should be:
def flipper_configure
  # Use a shared Memory adapter for all tests. This is instantiated outside of the
  # `configure` block so the same instance is returned in new threads.
  adapter = Flipper::Adapters::Memory.new

  Flipper.configure do |config|
    config.adapter { adapter }
    config.default { Flipper.new(adapter) }
  end
end

Is there any work around to prevent test_help.rb from being loaded, so that I can configure flipper myself, to avoid this? This is preventing me from upgrading to flipper v1.2

Hi @dannyy83, you're actually running into an issue with the strict adapter, introduced in https://github.com/flippercloud/flipper/pull/763. I'm guessing you're running Flipper 1.1? In 1.2 we disabled the strict adapter in tests because people were running into this issue. So you can either upgrade to 1.2 or manually disable it per the directions in the 1.1 release notes (see https://github.com/flippercloud/flipper/releases).
Let me know if that doesn't fix it for you.

Hi @bkeepers, I'm seeing this with the following environment:
flipper v1.2.2
flipper-redis v1.2.2
rails v7.1.3
rspec v3.13.0
ruby v3.3.0
My configuration for flipper is:
require 'flipper'
require 'flipper/adapters/redis'

Flipper.configure do |config|
  config.default do
    client = Redis.new(url: 'some_url')
    adapter = Flipper::Adapters::Redis.new(client)
    Flipper.new(adapter)
  end
end

I have no explicit flipper configuration in rspec, except for what's being automatically pulled in from https://github.com/flippercloud/flipper/blob/main/lib/flipper/test_help.rb

@bkeepers I've also tried to configure flipper as follows (as here https://www.flippercloud.io/docs/adapters/redis)
require 'flipper/adapters/redis'

And I still have the same issue.

I've also tried to disable the strict adapter as suggested:
Rails.application.configure do
  config.flipper.strict = false
end

And this has no effect.

Hi @bkeepers. I've done some more investigation on this, and tracked down the root cause of this problem to https://github.com/flippercloud/flipper/blob/main/lib/flipper/engine.rb#L71
I'm not sure why, but the call to flipper.strict returns the ActiveSupport::OrderedOptions instance, instead of the value of strict (which is false). So, the Strict adapter is being used.
To be more explicit, If I set a breakpoint on the above line, you can see:
> flipper.strict
=> {:env_key=>"flipper", :memoize=>true, :preload=>true, :instrumenter=>ActiveSupport::Notifications, :log=>true, :cloud_path=>"_flipper", :strict=>false, :test_help=>true}

> flipper.strict.class
=> ActiveSupport::OrderedOptions

# But, interestingly
> flipper.dig(:strict)
=> false

I've finally tracked down this problem...
In our test env, we also use the json_expressions gem (https://github.com/chancancode/json_expressions).
This gem adds a strict method to Hash and Array which returns a clone and unfortunately this method is called when flipper is initializing in our test env, which is truthy, causing strict mode to be enabled.

@dannyy83 wow, that's a fun one. I'm glad you figured it out! I'm not sure there's much we can do in flipper to work around that, but I'm open to suggestions if you have ideas.

Hi @bkeepers, I agree there's not much we can do for flipper to work around this issue. I don't have any suggestions.
For others that may see this problem, I worked around this issue by setting required: false in the Gemfile for json_expressions:
group :test do
  gem 'json_expressions', require: false
end

And instead manually load it in the rails_helper AFTER rails is loaded:
require 'json_expressions/rspec'


Unable to open jar file while scanning a directory

Hi,
We are trying to scan a directory using the latest version of dependency check and we are getting multiple warnings, like,
[WARN] Unable to open jar file 'guava-33.0.0-jre.jar'. .
This warning is there multiple times for many of the jars and this results in multiple CVEs being missed in the report.
On scanning the jars individually, we are getting the scan reports and not getting any warning.
Could you please help us out in finding out the possible reason for these warnings?

Enable the debug logging on your scan and in the log you should be able to find the full details on the IOException
https://github.com/jeremylong/DependencyCheck/blob/5df22e2a86ecef5822239122958403363f347641/core/src/main/java/org/owasp/dependencycheck/analyzer/JarAnalyzer.java#L1186

This is the debug logs that we got for the same issue:-
WARN  - Unable to open jar file 'Unable to open jar file 'guava-33.0.0-jre.jar'.'
2024-02-23 17:13:02,067 org.owasp.dependencycheck.analyzer.JarAnalyzer:1186
DEBUG -
java.util.zip.ZipException: zip file is empty
at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1781)
at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1562)
at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1495)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
at java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:724)
at java.base/java.util.zip.ZipFile.(ZipFile.java:251)
at java.base/java.util.zip.ZipFile.(ZipFile.java:180)
at java.base/java.util.jar.JarFile.(JarFile.java:345)
at java.base/java.util.jar.JarFile.(JarFile.java:316)
at java.base/java.util.jar.JarFile.(JarFile.java:269)
at org.owasp.dependencycheck.analyzer.JarAnalyzer.collectClassNames(JarAnalyzer.java:1173)
at org.owasp.dependencycheck.analyzer.JarAnalyzer.analyzeDependency(JarAnalyzer.java:308)
at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:88)
at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:37)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Sometimes these jars are getting scanned and sometimes we are getting these warnings.

java.util.zip.ZipException: zip file is empty
looks like somehow your infra is resulting in an empty jar file for the guava library

But I the jar file is not empty when I unzipped it manually
Also, this is not a consistent problem. The jars for which we the scanner is giving this warning, are getting scanned in some of the scans.

Hi @aikebah and @jeremylong
There are multiple problems for which we are seeking a solution. I will start with how we are using dependency check. We have a Jenkins job set up which we use to trigger the scanning for .parcel.tar.gz format zipped files using dependency check. We are using the CLI command to trigger the dependency check scans.
The issues that we are facing are:-
1.  Unable to open jar files:- This warning appears multiple times for many of the jars. When scanning the jars individually, we receive the scan reports without any warning. As I mentioned in my previous comment, the debug logs indicate ‘java.util.zip.ZipException: zip file is empty,’ but upon manual inspection, the zip file is not empty.
2. Inconsistency in the scanning of dependencies:- There are dependencies that are inconsistently identified and scanned by the tool. Sometimes, these dependencies are recognized during the scanning process, while other times, the tool fails to identify them. For example, ‘jruby-complete-<IP_ADDRESS>.jar’ has many dependencies, including ‘shaded snakeyaml:1.26.’ However, it often occurs that the ‘shaded snakeyaml:1.26’ jar is absent from the report. Upon rescanning the file, it reappears in the report. The configurations remain identical across all scans having inconsistencies, and it is noted that there is no evident pattern in the identification of dependencies.
3. Many times, not all the jars originating from another jar are included in the dependency check report. For instance, in the case of ‘jruby-complete-<IP_ADDRESS>.jar,’ ‘jruby-complete-<IP_ADDRESS>.jar’ shaded: ‘org.jruby:jruby-core:<IP_ADDRESS>’ is listed in the report along with some other jars from the same library. However, ‘jruby-complete-<IP_ADDRESS>.jar: snakeyaml-1.26.jar’ is not present in the report. But this thing happens while scanning the complete zipped parcel and not the individual jar.
These are the issues we are currently facing and we need your help to resolve them. Could you please provide some insights into the possible reasons for these issues and suggest actions we can take from our end to address them?

We would need sample projects that demonstrate this behavior. Additionally, I recommend switching to the maven or gradle plugin and not rely on the CLI.

Hi @jeremylong ,
We tried the maven plugin to scan our project and the number of CVEs increased by 230% and many of them are false positives.

Hi @jeremylong and @aikebah
We are facing the same issues with https://repo1.maven.org/maven2/com/google/cloud/bigdataoss/gcs-connector/hadoop3-2.1.2/gcs-connector-hadoop3-2.1.2-shaded.jar.

If this jar is present in our project, then dependency check is sometimes identifying two dependencies, jackson-core and google-http-client. Sometimes only one dependency, jackson-core and sometimes none of the dependencies. But not identifying any other dependency in any of the  scan.

Dependency check is able to scan the same shaded jar if scanned individually - On scanning the same shaded jar individually, the report has all the dependencies and CVEs, including the shaded guava dependency.

Dependency check is able to identify the CVEs in another version of the same shaded jar? - If gcs-connector-2.2.11-shaded.jar is present in our project then it is identifying the dependencies and CVEs coming through this version of the shaded jar.

Can you please have a look at this issue and provide us some suggestions that we can try to resolve these issues?

@Muskan-0618 please read my comment above: https://github.com/jeremylong/DependencyCheck/issues/6481#issuecomment-1973154379


Running daemon with Version 2.0 ends in NullPointerException

I have tested the refactored Version 2.0 on my RPI. But if i am starting the daemon, it ends in NullpointerExceptions every ms.
28 Apr. 2020 11:59:26,378 - ERROR:rocks.voss.musicsync.Application:main:47: Exception
java.lang.NullPointerException
	at rocks.voss.musicsync.Application.sync(Application.java:61)
	at rocks.voss.musicsync.Application.main(Application.java:42)

Does somebody else have this problem as well? @maximilianvoss any idea?

How have you started the musicsync? It seems like it did not detect any fitting input plugin.
Please check following file: https://github.com/maximilianvoss/spotify-toniebox-sync/blob/v2.0/package/src/main/resources/musicsync
It puts all generated jars into a classpath to run musicsync. Haven't had time yet to build a single jar with all dependencies included

I've got the same problem. Running musicsync script from package\target\output doesn't load any plugins:
Usage: spotify-toniebox-sync.jar [--daemon | --input INPUT --output OUTPUT]
--daemon
                Run in daemon mode to sync periodically all lists in the properties file
--input INPUT
                Define an input source for a one-time run
--output OUTPUT
                Define an output destination for a one-time run

Input Plugins:

Output Plugins:

I also tried to debug PluginLoader.java but it cannot find any subTypes in method loadPlugins(...). My environment is Ubuntu 20.04 LTS with openjdk-11. Do you have any idea why it's not working?

Hi @paschmal,
how do you launch the application? It seems that the plugins are not loaded/in your classpath.
Max

I´ve experienced the same problem that no plugins were loaded. I started the application via the script: ./musicsync --input spotify:playlist:... --output toniebox:...

I run the same command as @matthiaslau using musicsync script. I also tried to run it directly from vscode with explicit classpath set to the plugin jar files in launch.json, but that's not working either.

What JDK version do you use? It seems to be an issue with reflections

[~/src/music-sync/package/target/output]$ java -cp musicsync-application-2.0-SNAPSHOT.jar:musicsync-plugins-input-spotify-2.0-SNAPSHOT.jar:musicsync-plugins-output-filesystem-2.0-SNAPSHOT.jar:musicsync-plugins-output-toniebox-2.0-SNAPSHOT.jar:musicsync-plugins-output-toniebox-2.0-SNAPSHOT.jar rocks.voss.musicsync.Application --input "spotify:playlist:ZZZ" --output "toniebox:XXX:YYY"
Exception in thread "main" java.lang.NullPointerException
at rocks.voss.musicsync.Application.sync(Application.java:61)
at rocks.voss.musicsync.Application.main(Application.java:52)
[~/src/music-sync/package/target/output]$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1)
OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1, mixed mode, sharing)
Its an Ubuntu 18.04 derivative.

Thanks for confirmation. It seems to be a Java 9+ issue as the module management with Jigsaw has changed which prevents easy reflection. I will have a look to get this resolved.

Hi everyone, I tried to set up this project this weekend and ran into this same issue. Thanks for the note, that this is related to the java version. I downgraded to version 8 for testing (https://askubuntu.com/questions/1133216/downgrading-java-11-to-java-8) and got rid of this.
Unfortunately, I'm not able to log into the Toniecloud:

13 Sep 2020 12:44:20,901 - ERROR:rocks.voss.musicsync.plugins.output.toniebox.TonieboxOutputPlugin:openConnection:175: IOException while login
com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "errors" (class rocks.voss.toniebox.beans.toniebox.JWTToken), not marked as ignorable (one known property: "jwt"])
at [Source: N/A; line: -1, column: -1] (through reference chain: rocks.voss.toniebox.beans.toniebox.JWTToken["errors"])
at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:79)
at com.fasterxml.jackson.databind.DeserializationContext.reportUnknownProperty(DeserializationContext.java:555)
at com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty(StdDeserializer.java:708)
at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty(BeanDeserializerBase.java:1160)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:315)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:121)
at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:2860)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:1569)
at com.fasterxml.jackson.databind.ObjectMapper.treeToValue(ObjectMapper.java:1902)
at rocks.voss.toniebox.beans.Transformer.createBean(Transformer.java:23)
at rocks.voss.toniebox.beans.Transformer.createBean(Transformer.java:16)
at rocks.voss.toniebox.RequestHandler.executeRequest(RequestHandler.java:159)
at rocks.voss.toniebox.RequestHandler.executePostRequest(RequestHandler.java:125)
at rocks.voss.toniebox.RequestHandler.Login(RequestHandler.java:48)
at rocks.voss.toniebox.TonieHandler.login(TonieHandler.java:43)
at rocks.voss.musicsync.plugins.output.toniebox.TonieboxOutputPlugin.openConnection(TonieboxOutputPlugin.java:172)
at rocks.voss.musicsync.plugins.output.toniebox.TonieboxOutputPlugin.establishConnection(TonieboxOutputPlugin.java:126)
at rocks.voss.musicsync.Application.sync(Application.java:62)
at rocks.voss.musicsync.Application.main(Application.java:42)
13 Sep 2020 12:44:21,188 - INFO:rocks.voss.musicsync.plugins.input.spotify.SpotifyRecordingHandler:isFileValid:95: File doesn't exists
13 Sep 2020 12:44:21,188 - INFO:rocks.voss.musicsync.plugins.input.spotify.SpotifyRecordingHandler:downloadFile:37: Downloading: spotify:track:0yD2V18wbhNdFlE4rg3ovd

Spotify seems to work, at least it says that it tries to download. I double checked my toniebox login credentials. But the unknown field "error" suggest that something is wrong. Any ideas whats causing this? I get the same error with v1.3 and v2.0...


Updating the blog link

Originally pointing to the Windows blog, updated this to look at the Visual Studio blog.

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

Docs Build status updates of commit d2c2560:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/install/visual-studio-on-arm-devices.md
:bulb:Suggestion

Details

docs/install/visual-studio-on-arm-devices.md

Line 69, Column 20: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'Install' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 70, Column 18: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'Install' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 71, Column 18: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'Install' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

IMPORTANT: When this content is ready to merge, the reviewer must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

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

#sign-off

Docs Build status updates of commit fdb57db:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/install/visual-studio-on-arm-devices.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Implement vectorized message sending

In the current version, AppMetrics client sends single message per HTTP request. This works slowly and creates lag from message generation to the moment of delivery. It's necessary to send multiple messages per HTTP request.

done


Fix: add missing exit_stack.close() to end of /v1/completions endpoint

/v1/completions endpoint was missing an exit_stack.close() call

This was causing the llama proxy lock to be retained until exit_stack is cleaned up by garbage collector

#1798 supersedes this MR as I found thread starvation issue was not just due to improper closing of exit_stack but due to thread starvation from dependency pull of llama_proxy locking all worker threads


consider moving transport to devDependencies

See
https://github.com/cardano-foundation/ledgerjs-hw-app-cardano/pull/4

No one is asking for this; the workaround in the above PR is perhaps more fragile.


Cannot load converter in WATS client

Hi Virinco
I have followed the guide for installing the Listen converter. (https://github.com/Virinco/WATS-Client-Converter-Listen).
I installed WATS client <IP_ADDRESS> (64bits).
I have successfully logged into my account in the client.
I downloaded the Listen converter.
I created a new converter. Loaded the .dll from the Listen .zip file.
Error: the class field is empty.
Hope you can help
Br,
Morten

Hi,
Try unblocking the file (or the zip)

Thank you. After unblocking the file, the issue is gone.


add naive approach to token refresh

Fixes #78
Overview
Prevents users from needing to manually re-authorize by refreshing tokens as necessary before they are used. This is accomplished by ensuring they are valid before returning them in the new get method.
Discussion
A quick run-through of the codebase revealed no further usages of the client.garden_authorizer.access_token, but any current and future uses of this property should instead be replaced with the new get method _get_garden_access_token().
Testing
This is a rather annoying problem to test, however, it could be done by simply waiting on an old token.

:books: Documentation preview :books:: https://garden-ai--149.org.readthedocs.build/en/149/

Codecov Report

Merging #149 (34de35d) into main (24dcc9f) will increase coverage by 0.05%.
The diff coverage is 40.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #149      +/-   ##
==========================================
+ Coverage   80.67%   80.72%   +0.05%
==========================================
  Files          43       46       +3
  Lines        2515     2693     +178
==========================================
+ Hits         2029     2174     +145
- Misses        486      519      +33

Impacted Files
Coverage Δ

garden_ai/client.py
54.74% <40.00%> (-0.37%)
:arrow_down:

... and 8 files with indirect coverage changes


 PTAL

/lgtm

@sftim lgtm from your side as well?

All fine by me. @bertinatto looks like this needs a rebase though?

@sftim @msau42, rebased! PTAL

/lgtm

/approve


Indicator duplication

Indicator will be duplicated when controller presented many times,
can you fix this issue as soon as possible :)
Thanks.

Thanks! I am fix it today!

I am reales new version 1.5.4, please, update pod. Thanks for your help!

perfect 👍


fix(langchain-adapter): fix how tool calls are being separated and read

Our LangChain adapter was failing to work with a "one at a time" tools. Tools that should be used multiple times with one argument or so.
This PR introduces some changes to make this available, as well as a change to our demo to integrate such action
Checklist

[X] I have read the Contribution Guide
[X] If the PR changes or adds functionality, I have updated the relevant documentation

In favor of different solutions, closing this, as it became irrelevant


Add the reranker score and captions in the search results.

Description
Add the semantic reranker score and captions in the search results.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Thanks for the contribution. Can you please clean up your PR?
Seems like there are too many changed files.

Thanks for the contribution. Can you please clean up your PR?
Seems like there are too many changed files.

@LucasVascovici please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

Contributor License Agreement

@microsoft-github-policy-service agree [company="{ELCA}"]

@LucasVascovici the command you issued was incorrect. Please try again.
Examples are:
@microsoft-github-policy-service agree

and
@microsoft-github-policy-service agree company="your company"

@microsoft-github-policy-service agree company="ELCA"

@LucasVascovici please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

Contributor License Agreement

@microsoft-github-policy-service agree company="ELCA"

Thanks for the contribution. Can you please clean up your PR?
Seems like there are too many changed files.

Changed the merge destination from develop to main

Those failures are real issues.
Could you help fix them?

/azp run python - search - ci


Private properties support

TypeScript supports private properties since v3.8.0, which this library fails to recognize:
class Test {
    /**
         private property example.
    */
    #prop: number = 123;
}

This library throws  Invalid character error, which stops us from using this new TypeScript feature, because then we cannot generate documentation.
I'm not sure if this shouldn't be labelled as a bug. At least, this should be a high-priority feature/fix.

Workarounds:

Use typedoc@next - TS is moving to a peer dependency, but the library mode feature isn't done yet so not a full release.
Remove node_modules/typedoc/node_modules/typescript to force TypeDoc to use your version of TS. Properties will show up documented with the name #name (but I don't think they are correctly marked private)

I should have time this weekend to pull the parts of my original plan for 0.17 that are done into master and re-schedule library mode for 0.18.

Thank you for quick response!
For now, as a work-around, we use WeakMap instead, which is what TypeScript transpiles private properties into (when generating es5 code).

Fixed with 5d41a2e03a4cefa29ae84e7f9ef409d976d4ac56, release as soon as I get done going through issues and making sure I got everything.


Additional video options

Adding in the ability to do 2-pass encoding
Allowing user to disable video resizing
Allowing user to force a video encode even within the same codec

Thanks for the recommendations, both have been pushed. Would you like me to squash this commit as well?

Oups sorry I forgot to merge your PR before mine (#421), so now you get some conflicts :(
It should be easy to fix, just 2 lines in process_video, but I can do it if you prefer.
Also thanks for the change, looks good.

No problem, conflict should be resolved. Merge whenever! Thanks

Thanks!


Remove usage of deprecated "$errcontext" parameter

The $errcontext parameter for the callback used with set_error_handler was deprecated in PHP 7.2 and removed in PHP 8. Usage of it causes the following error
ArgumentCountError: Too few arguments to function TinCan\RemoteLRS::TinCan\{closure}(), 4 passed and exactly 5 expected

https://www.php.net/manual/en/function.set-error-handler.php#refsect1-function.set-error-handler-parameters

@spheresh Could you please take a look at this when you have a moment?

@mattcmonte Thanks for your contribution to the project.
I've opened the issue https://github.com/opigno/TinCanPHP/issues/3 because the version of php should be changed to >=8 by reason of this change.  Additionally, we can consider some additional improvements to composer.json


Windows Container Tags have wrong units on Size field in Web UI

For example, if I push microsoft/windowsservercore (a 10.5gb image when extracted), it shows up in the web UI as taking only 5.02MB:

However, the API returns<PHONE_NUMBER> for the size, which I assume is the compressed size in bytes:
~/Documents/WindowsPowerShell/Modules/Harbor.PowerShell/1.0.52$ Get-HarborTag nlowe/windowsservercore

Repository              Name   Author Architecture OperatingSystem DockerVersion CreatedAt            Digest
----------              ----   ------ ------------ --------------- ------------- ---------            ------
nlowe/windowsservercore latest        amd64        WINDOWS                       3/13/2018 2:11:07 PM sha256:f0e539ed8bc4a1f5f059ede3ba165364be0dfead1d5a0cc6a5aa33ee909fbfe8

~/Documents/WindowsPowerShell/Modules/Harbor.PowerShell/1.0.52$ Get-HarborTag nlowe/windowsservercore | Select Repository,Name,Size

Repository              Name         Size
----------              ----         ----
nlowe/windowsservercore latest<PHONE_NUMBER>

~/Documents/WindowsPowerShell/Modules/Harbor.PowerShell/1.0.52$<PHONE_NUMBER>/1gb
5.01906738802791

If I'm way off base here please let me know.
We're running Harbor 1.4.0

looks like a bug in ui?  Is it fixed already?

I'm seeing same issue on 1.4.0. It used to work when we were using 1.2.x versions.

@pureshine , please check if this still exist